Re: On autogenerated ChangeLog
- From: Garrett LeSage <garrett novell com>
- To: "Zeeshan Ali (Khattak)" <zeenix gmail com>
- Cc: desktop-devel-list <desktop-devel-list gnome org>, gnome-infrastructure <gnome-infrastructure gnome org>, Bastien Nocera <hadess hadess net>, Murray Cumming <murrayc murrayc com>, Alexander Larsson <alexl redhat com>
- Subject: Re: On autogenerated ChangeLog
- Date: Tue, 21 Apr 2009 23:13:25 +0200
On 04/21/2009 10:23 PM, Zeeshan Ali (Khattak) wrote:
1. All information in the ChangeLog is redundant.
2. Maintaining a ChangeLog only and only realizes otherwise
inexistent conflicts.
Agreed.
You could do what we've been doing in a project of mine:
Auto-generating the changelogs on release, and publishing a hand-picked
"friendly" changelog too.
In fact, you probably should have a file which would be updated as
developers churn along (distributing the effort over time), where each
big notable feature/bugfix/etc. is recorded as a line in the file
whenever it officially lands. When you make a release, create a tag in
git (using "git tag -a" of course). When you diff the file between tags
(this can be done easily if you have a "release" branch which always
points at the most current release) and extract only the new lines, you
have a changelog of well-written, user-friendly features — perfect for
posting to your project's website, sending out to a mailing list, etc.
Then, for those who want a more traditional "here's-everything"
changelog, just generate a changelog based on your git commit messages.
This should also be done also automatically on release.
The nice thing about a process like this is that it minimizes the effort
needed (since it's all done automatically using git, at release time)
and should make everyone happy.
Garrett
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]