On Thursday 27 March 2014 07:25:20 John Ralls wrote: > On Mar 27, 2014, at 2:13 AM, Geert Janssens <[email protected]> wrote: > > On Saturday 22 March 2014 18:39:13 John Ralls wrote: > > > On Mar 22, 2014, at 4:01 PM, Geert Janssens <[email protected]> > > > 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. Geert _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
