[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: layout change for CHANGES

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Sat, 19 Sep 2015 15:29:02 +0300

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.

> 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
tarballs.

Nevertheless, I think that it's a good thing to keep in mind for the future
changelog entries. Thank you for sharing the thoughts.

[1] https://subversion.apache.org/docs/community-guide/releasing.html#the-changes-file

Regards,
Evgeny Kotkov
Received on 2015-09-19 14:29:41 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.