On Mar 27, 2014, at 2:13 AM, Geert Janssens <janssens-ge...@telenet.be> wrote:
> 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. 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. 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. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
