On 19.09.2015 14:29, Evgeny Kotkov wrote: > Stefan Hett <[email protected]> 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
