> On 21 Jul 2016, at 23:59, Chris Nauroth <[email protected]> wrote: > > While working on the 3.5.2-alpha release, I noticed that CHANGES.txt in trunk > is not completely synchronized with the 3.5 release line. In branch-3.5, we > have sections for releases 3.5.0, 3.5.1 and 3.5.2 (added by me), each > indicating their respective release dates. In trunk, release 3.5.0 is > mentioned, but not release 3.5.1. I have not yet added anything about 3.5.2, > because I wasn't sure if the omission of 3.5.1 was an oversight or > intentional. > > More generally, it appears that on any given branch, CHANGES.txt does not > comprehensively cover the prior major release lines. On branch-3.5, > CHANGES.txt mentions release 3.4.0, release 3.3.0, etc., but not any of the > subsequent releases in those lines, like the recent 3.4.8.
In the first paragraph, you mention that trunk mentions 3.5.0, but not 3.5.1. On the 3.5 branch, we mention 3.3.0 and 3.4.0, but not the subsequent release. I think in both cases it is just an artifact of starting a new trunk branch as soon as we cut the first release of a branch. There is no inconsistency afaict. For example, when we cut the 3.6.0 release, we will start a new trunk and trunk will have a mention to 3.6.0, but not subsequent releases of the 3.6 branch. > > Is this something we need to correct? Is it even worthwhile to keep > maintaining CHANGES.txt, or is it not worth the effort? FWIW, other projects > like Hadoop and HBase have abandoned maintaining CHANGES.txt files and > instead rely on the revision log for patch attribution and various forms of > automation for generating release notes. > I'd be fine with using the revision log. -Flavio
