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?
If so, can we find another solution for that?
(PS: I'm not trying to be pedantic / drag this on forever. Just trying
to explore whether things can be improved...)
--
Johan
Received on 2018-07-17 10:05:44 CEST