Thanks for this release DFINITY!
I wanted to make sure that I understood what was happening here, as it’s unusual and really not obvious. I filtered my git client to show only the two relevant branches to cut down on all the noise, and then produced this modified screenshot to illustrate the situation (highlighting the ‘merge base’ commit that’s referred to in the proposal summary, along with the previous release and this proposal’s release).
You can see that the previous release is left out on a limb and is never merged (effectively discarding that commit with respect to this release). The discarded commit isn’t actually a GuestOS commit (what a distraction 
).
Just a final comment on the matter - the commit is actually cherry picked back into this release branch (so actually the changes aren’t really discarded after all, they are included in this release… 
). Not only that but the commit includes a few subtle additional changes this time around.
The point I’m emphasising is that the IC repo uses git in an unconventional way that makes it very difficult to get a handle on what’s going on. There’s no reason the original commit couldn’t have been merged into the new release branch, and an additional commit made for the updated changes. This approach would have:
- Avoided the distracting and inaccurate comment about changes being removed
- Avoided unnecessary release branch divergence
- Saved me (and perhaps others) unnecessary effort to understand what’s going on
- Made it extremely easy to track with Git GUIs capable of visually representing this. I’ve illustrated this previously → Proposal to elect new release rc–2024-07-25_21-03 - Governance - Internet Computer Developer Forum (dfinity.org)
I’d expect these to be goals for any Web3 project that’s serious about governance decentralisation. Is there any chance of introducing best practice policy to improve matters here @basvandijk?