On 19.09.2015 14:29, Evgeny Kotkov wrote:
> Stefan Hett <luke1410_at_gmx.de> writes:
>
>> I'm wondering whether it'd be a good idea if entries in the changelog were
>> sorted by its category. This mostly applies to the "Client-side bugfixes"
>> but I think it would slightly improve the readability by users because:
> [...]
>
>> Here's how a differently sorted changelog for 1.9.2 could look like:
>>
>> Version 1.9.2
>> (30 Sep 2015, from /branches/1.9.x)
>> http://svn.apache.org/repos/asf/subversion/tags/1.9.2
>>
>> User-visible changes:
>> - Client-side bugfixes:
>> * checkout: remove unnecessary I/O operation (r1701638)
>> * checkout/update: fix "access denied" error on Windows (r1701064 et al)
>> * commit: fix possible crash (r1702231)
>> * merge: fix crash when merging to a local add (r1702299 et al)
>> * merge: fix possible crash (r1701997)
>> * ra_serf: do not crash on unexpected 'X-SVN-VR-Base' headers (r1702288)
>> * revert: fix crash when reverting the root of a move (r1702237 et al)
>> * svn: fix crash when saving credentials in kwallet (r1700740, r1700951)
>> * svn: do not crash upon specific database corruptions (r1702974,
> [...]
>
> Indeed, the changelog with grouping looks more readable in this particular
> example. Based on older entries, I don't think that we've been doing this
> sort of grouping — i.e., some of the entries are locally grouped, but there
> is no grouping overall.
>
> The Community Guide doesn't say something about it, except for "Read that log
> from oldest to newest, summarizing points as you go." [1]. I did that for
> the 1.9.2 part of the changelog, and I also used the 1.8.9 changelog as
> reference, as these releases are somewhat similar in the amount and types
> of changes.
We tend to order the entries by revision. That may not be the best
choice, but that's how it's been more or less since day one.
I don't mind reordering the 1.9.x entries, but please don't touch
anything earlier than that because it'd be a real pain to merge to 1.8.x
and older (that merge is already a bit of a pain, so let's not make it
worse).
-- Brane
Received on 2015-09-19 14:45:41 CEST