On 17/07/2018 10:37, Branko Čibej wrote:
> 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
+1 on that
There are quite a lot of benefits of having a complete changelog
available even for bugfix releases of previous minor releases. I
certainly can't come up with all and I also can't think of any "big"
ones which one would argue in the end outweights the hassle for the
release overhead. But then the release overhead isn't that much work
either as far as I see it (speaking here maybe of ~30 mins even for a
coordinated release for two versions, right?).
Just some examples where I used it myself in the past:
* looking up the changelog in my local installation to see if a user
reported issue (be it on the mailing list or at work) was resolved
in his older SVN version already
* identifying issues which were already fixed on the current version's
branch but were not yet backported to the previous version
* just reading up old changelog entries out of interest
As stated, none of these are major arguments against changing our
process, but still I'd personally miss a complete changelog. That said,
if the majority of the team is fine with a change, so will I be in the
end and won't argue against it.
Regards,
Stefan
Received on 2018-07-17 11:17:44 CEST