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