On 17.07.2018 10:05, Johan Corveleyn wrote:
> On Tue, Jul 17, 2018 at 9:03 AM, Branko Čibej <brane_at_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
Received on 2018-07-17 10:37:41 CEST