Re: git structure and release policy

[Gavin Smith]

On Tue, Nov 08, 2022 at 07:07:49PM +0200, Eli Zaretskii wrote:
> > What kind of structure should we use to apply fixes to both the main
> > line of development and to the release branch?
> 
> There are basically 2 workflows:
> 
>   . fixes for the release branch are committed to that branch, and the
>     release branch is merged to master from time to time
>   . all fixes are committed to master, and fixes which are safe for
>     the release branch are then cherry-picked to the branch
> 

Thanks for the info.  It seems that we would always want to fix everything
on master by default, so the second approach seems better.

When we did a new major release, would we merge "master" into "release"?
Would this keep all the commit ID's from commits on the "master" branch?
Does this still work even if a change already exists on the "release"
branch or if a change on the "master" branch conflicts with something
on the "release" branch?

> 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.

> > Would we continue the main line development on the "master" branch, or
> > on a separate branch?
> 
> The former is simpler, IMO, as it minimizes the number of branches.

OK.

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.

> > Since there are not many people making commits to the Texinfo code, I
> > doubt that it would be useful to have a lot of "feature branches".  There
> > are benefits to everybody testing and running the same code to get problems
> > found and fixed quickly.  However, if someone has a better idea of how
> > git branches should be used, please feel to reply.  (I haven't spent much
> > time researching the topic.) 
> 
> Feature branches are good for long-term projects that don't want to be
> obliged to keep the master branch stable and not broken.  Otherwise,
> development directly on master is better, IMO.
> 
> Just my $0.02.