Re: git structure and release policy

[Eli Zaretskii]

> From: Gavin Smith <gavinsmith0123@gmail.com>
> Date: Tue, 8 Nov 2022 16:34:03 +0000
> 
> We have always developed Texinfo in a linear fashion (in git and before
> that SVN).  However, the development repository is not necessarily always
> in a fit state to be released with new work being done.  So one question
> I have is, if we were to make minor, bug-fix releases, should these be
> on a separate branch that starts at the previous release?

Many projects do that, yes.  Examples: Emacs, GDB, Gawk.

> 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

> Another question is how we handle ChangeLog entries when merging branches.

One possibility is to use git-merge-changelog, which is a program that
is part of Gnulib.

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

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