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.
