Branching strategy for git

[Geert Janssens]

On Saturday 22 March 2014 18:39:13 John Ralls wrote:
> On Mar 22, 2014, at 4:01 PM, Geert Janssens <janssens-geert at telenet.be> 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.

Geert