re release branch and guix pull: what happens when someone installs a branched 2.8.1 release and then first invokes a guix pull?
i assume it should pull from the then current master. but wouldn't that lead to a downgrade warning, short of some special machinery recognizing and ignoring this situation? Sent from mobile, pardon/enjoy my brevity -------- Original Message -------- On Wednesday, 12/10/25 at 07:25 Ian Eure <[email protected]> wrote: Hi Rutherther, Rutherther <[email protected]> writes: > Thanks! I am still thinking about the best way to continue > forward and > am unsure. What are your thoughts on merges/rebases to keep > next-master > updated with updates from master? There’s a fundamental tension between ordinary dev activity and work to firm up a release, and effectively two ways to handle that: You can use your default branch for the release, and do the ordinary dev work in a different branch, which is what we’re doing here. I’ll arbitrarily call this the "freeze default branch" approach. Alternately, you can do the release work in a branch cut off the default one, which I’ll call the "release branch" approach. Neither solution is perfect, so it’s a matter of picking your tradeoffs. Freeze default branch: - Pro: Easier to manage commits. You can rebase next-master onto master to get those changes, and after the release, merge next-master into master, then delete next-master. - Con: Disrupts ordinary dev work, as all non-release work has to shift to another branch. - Con: It works poorly for maintaining releases over long timespans. Since normal dev work resumes against this branch, it will churn, and it’s difficult to apply targeted fixes if you need a 1.5.1 release. - Con: It doesn’t work at all (or gets changed so much it doesn’t resemble my description) if you need to support multiple releases at once, like if you have a faster-moving release and LTS. Release branch: - Pro: Doesn’t disrupt ordinary dev work. For projects with many contributors or lots of activity, this is very important. - Pro: Long-term maintenance is easier. Say you want to relase version 2.8.0 of your project, you’d cut a release-2.8.x branch for that, get it into shape, then tag v2.8.0, and leave the branch. If you need a 2.8.1 release, you’d cherry-pick fixes from the default branch into release-2.8.x, then cut the 2.8.1 release tag from it. - Con: More work to move changes between branches. In the very early stages of the release, you’d want to merge or rebase the release branch against the default, but when you hit code freeze, you have to control which changes make it into the release. Which means cherry-picking from the default branch... which means divergent histories, which means merge and rebase are can’t be used. My personal experience is that freeze default branch is a good fit for smaller projects -- it makes up front stuff a bit easier, and the things it makes harder tend not to be relevant. For larger projects or ones with support committments, you do a bit more work up front to make the long term stuff feasible. I’m writing all this not to say we should change what we’re doing for this release -- we shouldn’t -- but to give some context when we’re looking back at this release when we begin preparing for the next. -- Ian
