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
