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