>I agree enterely. My proposal is to gzip and leave the current ChangeLog
>as historical reference, then start from scratch with a new one, but
>much more terse and user-oriented (ready to be cut'n'paste-d into the
>release annoucement).
>Something like that
>
>[TYPE] - date - author (email)
>* component: max-three-line-description
I think we can make it even more concise than that, depending on how much
information you want to keep in the file. Here's an example of how I did
it in another project (IRC Services):
=======================
Version 5.1
-----------
2008/12/07 .14 Fixed potential infinite loop on detecting a fatal error.
Reported by Jille Timmermans <ji...@quis.cx>
2008/12/07 Fixed race condition in which Services might fail to send
its initial data to the server if the connection took
too long. Reported by Alexander Barton <a...@barton.de>
[...]
=======================
In this case, I was the only developer, so there was no issue of who made
the change (though I did note where suggestions/bug reports came from);
but even for transcode, does it really matter to the users which of us
committed each particular change? After all, we have the Mercurial log,
and if nothing else, one could look up where a particular ChangeLog entry
was made and see who committed it. For that matter, dates probably aren't
important for the same reason, so we could even trim it down to something
like:
=======================
transcode-1.2.0
---------------
[+] New module system implemented.
[+] Added some weird option to transcode.
[*] Default number of buffers increased to 17.
[*] Fixed crash with -i /dev/urandom.
[-] Support for DivX 0.x (ancient) removed.
=======================
and maybe fill in the date when we release, like with the transcode-0.6
entries in the current ChangeLog. What would you think about that? (We
could also have explicit lists of additions/changes/removals instead of
the +/*/- marking if you think that'd be better.)
--Andrew Church
achu...@achurch.org
http://achurch.org/
