On 17.07.2018 10:05, Johan Corveleyn wrote: > On Tue, Jul 17, 2018 at 9:03 AM, Branko Čibej <br...@apache.org> wrote: >> On 16.07.2018 21:46, Johan Corveleyn wrote: >>> (why would CHANGES in a 1.9.x tarball need to contain changes of the >>> 1.8 line?) >> Because I, as an admin, want to see the whole relevant history in >> CHANGES when something breaks and I have to fix it. > Hm, okay. > However, Daniel had a good point about what's actually *relevant* history: > > On Mon, Jul 16, 2018 at 9:54 PM, Daniel Shahaf wrote: >> I see no reason for a 1.9.x tarball to contain the CHANGES stanzas of >> 1.8.y with y>1, since the contents of those sections are repeated under >> 1.9.x sections, but I do see a reason for 1.9.x to contain the 1.z.0 >> CHANGES entries even for z<=8: bugfixes listed in those section are >> included in the subject tarball and aren't listed under any 1.9.x >> CHANGES section. > That means we could do the following: > > 1) trunk/CHANGES: only keep the changelog of every 1.x.0 version > (including the unreleased trunk changes for the future 1.x.0), no > 1.x.y sections with y > 0. > > 2) Every release branch starts with its normal branch copy of > trunk/CHANGES (containing all 1.x.0 changelogs until then). With every > patch release, only the corresponding branch copy is updated (not > trunk, and not any other release branches). > > Would that work? No more merging, and every release branch (and tag / > tarball) has the preceding minor releases plus all relevant patch > releases. > > The only downside I see is that trunk/CHANGES no longer contains the > entire changelog of all our patch releases. Is that really necessary?
Depends. For software archaeologists — and as our own aide-mémoire — it would be nice to have the changelog in one place. After all, it's an editorial work that's far more useful than a simple 'svn log'. Breaking all that historical info across who knows how many branches seems like a step backwards; analogous how to breaking up a single large repository into thousands of tiny modules would make version control harder (gitficionados, please note). -- Brane
