Thanks for this release DFINITY🙂
For anyone interested in the divergence mentioned in the change summary, here’s the relevant part of the git graph →
The…
- previous executed release (described as a ‘removed commit’ in the proposal summary),
- the ‘same change under a different commit’,
- and the ‘merge base’ commit
… are all highlighted in blue above (and labelled to make it clearer).
I’ve verified that the ‘removed commit’ and ‘same change under a different commit’ are binary equivalent. This step (on the part of a reviewer) could be easily automated for merge requests (due to the clearly modelled relationship between a source and merge commit). Cherry picked commits have a much looser relationship (as is the case with the previous executed release/‘removed commit’).
If the previous executed release branch had been cut using a merge commit rather than a cherry picked commit the git graph would also have been much clearer, e.g. →
Merging the previous executed release back into main in the example above is an unnecessary step, but I think it’s visually clearer (indicating that there’s actually no divergence).
I’m coming at this from the stand point of a reviewer seeking as many ways as possible to make IC-OS releases easier and more convenient to verify and review (in the hope that more people will be more likely to get involved in the future).
Do you have any thoughts on these ideas @DRE-Team? My thinking is that this sort of approach avoids the need to explain any kind of divergence (as in this proposal summary).