git structure and release policy

[Gavin Smith]

I thought we could discuss whether we should use any kind of git branch
structure for the development of Texinfo.  A related question is whether
we should do minor releases for bug fixes and translation updates.  For
example, shortly after Texinfo 6.8 was released (in July 2021), glibc 2.34
was released (in August 2021) which broke compilation of Texinfo.  It might
have been good to have made a new release at that point (e.g. 6.9 or
6.8.1).  It is frustrating to have a known problem that is stopping
the project being built for some users.  A less severe problem was that
the "info" program would crash if the user's language was set to
Brazilian Portuguese.

I know distributions (like Debian) often have a very limited number of
patches which they apply to releases for fixes such as this.  When there
is a fix it would be good to be able to make a quick release with just
that fix in it.

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?  What kind of
structure should we use to apply fixes to both the main line of development
and to the release branch?

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

Would we continue the main line development on the "master" branch, or
on a separate branch?

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