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)
> 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." . 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
> If you determine that'd be a good idea, I'd offer to update the CHANGES for
> all 1.9.x release notes accordingly.
I don't think that we should be rewriting the changelog, as this would result
in having different /CHANGES sections in the repository and in the released
Nevertheless, I think that it's a good thing to keep in mind for the future
changelog entries. Thank you for sharing the thoughts.
Received on 2015-09-19 14:29:41 CEST