On Saturday 22 March 2014 18:39:13 John Ralls wrote: > On Mar 22, 2014, at 4:01 PM, Geert Janssens <janssens-ge...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
