Maxim Cournoyer <[email protected]> writes: > Hi, > > Noé Lopez via "Development of GNU Guix and the GNU System distribution." > <[email protected]> writes: > >> Hi everyone, >> >> Just a reminder that as of today, the toolchain and transition freeze is >> active. Please do not push any changes that would cause major >> transitions to master. >> >> Major updates to packages can still be pushed until December 1st with >> some considerations: >> >> “Any change that alters a significant number of packages should be >> carefully considered and updates that cause other packages to break >> should be rejected.” >> - GCD 005 >> >> You can still develop them on your team branches and keep them until >> December 1st, when there will be a next-master branch that can receive >> those changes. >> >> Thanks for your cooperation. > > I think I've already mentioned this before (during the GCD perhaps?), > but why force everyone on a master-next branch when the release team (a > smaller set of people) could instead branch current master into > 'release-1.5.0' and issue a release from it, leaving the rest of the > world continuing as normal? > > The release branch would accumulate a few commits, which would later be > _merged_ into master at some points (_not_ rebased, to avoid rewriting > them since the release tag would have been placed on a commit of that > branch, which shouldn't change, e.g. for 'git describe' to print > something sensical). >
Hi Maxim, We’re trying to follow the process suggested in GCD 005 as close as possible. As far as I understand, many choices have been made in it to prioritize having the releases done before anything else, so it was probably a conscious choice to make it easier for the release team. I am not the author though so I might be wrong. The GCD explains this rationale: >If there are major breaking changes that must be moved from a team >branch an integration branch will be created. For example next-master, >this will be short-lived, existing only until after the release. > >The master branch slows down from this week until the release. > >This concept comes from the Nix project where they flow big changes >into a staging branch while they do release stabilisation to prevent >big flows of breaking changes into master which broke one of their >releases ^6. The master branch will keep receiving any commit that is not a major change. Package additions, updates and fixes can still go there if they are “safe” enough. It does not become exclusive to the release team. Does that make sense? I’m sorry if it was not clear in my previous messages. Good day, Noé
signature.asc
Description: PGP signature
