Re: git structure and release policy

[Eli Zaretskii]

> From: Gavin Smith <gavinsmith0123@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.