Branching strategy for git

Geert Janssens janssens-geert at
Thu Mar 27 10:45:23 EDT 2014

On Thursday 27 March 2014 07:25:20 John Ralls wrote:
> On Mar 27, 2014, at 2:13 AM, Geert Janssens <janssens-geert at> wrote:
> > On Saturday 22 March 2014 18:39:13 John Ralls wrote:
> > > On Mar 22, 2014, at 4:01 PM, Geert Janssens <janssens-geert at> wrote:
> > > > I like the workflow as proposed in the git workflows man page
> > > > (section Branch management for a release and following). They
> > > > propose a long-term maintenance branch. Only when a new feature
> > > > release is done, a separate maintenance branch for the previous
> > > > stable series is created. So when 2.8.0 gets tagged, the current
> > > > head of stable is branched off into stable-2.6. Then stable is
> > > > fast
> > > > forwarded to the 2.8.0 release tag.
> > > 
> > > It won’t quite fast-forward because of ChangeLog and NEWS, but
> > > those
> > > are minor issues; the releaser can just resolve to the new
> > > version.
> > 
> > Zooming in on this issue:
> > 
> > If I understand the release process well NEWS is hand-written (based
> > on a preformatted log since previous release) and Changelog is
> > autogenerated from the git log.
> > 
> > Looking at both files I see that NEWS groups changes per version
> > while Changelog just lists changes by date.
> > 
> > Let's assume we're in the current situation: 2.8.0 has been released
> > and there are a couple of bug fixes that will appear in both 2.6.x
> > and 2.8.1. What should come in the NEWS file ? For the 2.6.x
> > release there should be a section listing the changes in 2.6.x. For
> > the 2.8.1 release I would expect both a section for 2.6.x (assuming
> > this gets released right before 2.8.1) and one for 2.8.1.
> > 
> > I'll note that this didn't happen for 2.4.x and 2.6. From the first
> > 2.5.x release the NEWS file on trunk wasn't updated with 2.4.x
> > releases anymore. That looks like a flaw in our release
> > infrastructure that didn't get noticed because of the weak merging
> > capabilities of svn.
> > 
> > With git this can be handled better because if we merge the 2.6.x
> > release changes upwards that would bring in the 2.6.x release
> > section. It may cause a merge conflict but at least we're informed
> > there is a new section to add. I'm not even sure this would create
> > a merge conflict because the existing news sections don't change.
> > Only a new one gets added. The only way to be sure is to test.
> > 
> > Changelog may be more difficult though we'll have to run a test to
> > be sure. The main question for me here is whether or not our code
> > to generate the Changelog file can properly handle multi-parent
> > commits ? This is important to generate log entries for the changes
> > from upwards merged bugfixes into master. If it does, then merge
> > conflicts when merging maint into master can always be resolved in
> > favour of the Changelog file on master.
> I'm actually in favor of deleting both because I don't think that
> anyone ever looks at them. I expect that everyone gets the News
> information from the website or email if they even bother to read
> past the subject line, and uses the history from git log, their git
> GUI, or on Github to see what was committed and when.
I don't have a strong preference. I'm just putting up objections to be sure we don't miss 
anything :)

One such thing is that I seem to remember distcheck will fail in the absence of either NEWS 
or Changelog. I don't know if this is hard wired in the autotools chain or just because of the 
way our makefiles are constructed.

Secondly I wonder if distro's care about either file. Individual users perhaps less so.

> That said, if we do continue them, then I agree that resolving NEWS
> won't be that hard. The worst case will be if there's been an
> unstable release between two stable releases, and one need only
> remove the <<< === >>> lines and add the file.
> I don't think ChangeLog is a big deal either: The automated generation
> will reflect all of the changes since the previous release on that
> branch, including the ones merged in from 'maint', so one can just
> resolve in favor of the new version and be done with it. It would be
> worthwhile to play around with the merge styles a bit to see which
> one produces the fewest conflicts.
That's more or less as I see it as well.


More information about the gnucash-devel mailing list