> From: Gavin Smith <gavinsmith0...@gmail.com> > Date: Tue, 8 Nov 2022 19:34:51 +0000 > Cc: bug-texinfo@gnu.org > > When we did a new major release, would we merge "master" into "release"?
No, you just cut a new release branch. The release branch is only for a certain release or a series of releases, depending on the development strategy. Basically, as long as you expect the next release to be a bugfix release, you keep developing it on the same release branch, and once you decide on a feature release, you cut a new release branch. The name of the release branch can be the first version released from that branch, or some variant of that. > > One possibility is to use git-merge-changelog, which is a program that > > is part of Gnulib. > > We use that already, so hopefully it will be fine. It seems that > the order of changelog entries may change on the release branch though, > to put cherry-picked commits earlier in the file. I wonder if we > should mark such commits specially in the ChangeLog file somehow. I doubt that the order matters. > So what it seems we need to do is create a new "release" branch (I don't > see why it can't be called "release") and only commit to it in very > limited circumstances. See above: I suggest to change the release branch each time you start a new series of bugfix releases. So, for example, the release branch for Texinfo 7.1, 7.2, etc. could be named texinfo-7.x or maybe texinfo-7.0-release. Then, if we decide that Texinfo 7.5 will be a feature release, we cut a new branch named texinfo-7.5-release. I don't recommend to keep a single release branch across feature releases.
