Tracking Changes

[BJ Dierkes]

Wanted to start a discussion regarding how to track, and present changes for each release. Currently we've tightened up our Git commit logs which are the obvious source of change history, however we need to provide a list of changes per release when releasing new stable versions.

To that... we need to standardize some fashion of 'Release Notes' for each release... which includes the changes. This is difficult, because there is nothing in the logs that makes it clear that "The changes for x.y.z release start here". There are some unofficial 'bumping version here' comments, but nothing standard.

How should we handle this? I am perfectly ok with mocking up git logs to be a prettier list of relevant changes... but I need to know where the release started in those changes.

Thoughts?

---
BJ Dierkes
Linux Systems Engineer IV / [RH]acker
Infrastructure Services [Development]
Rackspace Hosting

[Tim Soderstrom]

I am a fan of release notes myself. I think perhaps leveraging GIT issues might be a good thing here so we can do something like:

* Implemented mysqldump-lvm provider [GIT Issue #xyz]

Or perhaps for standard commits, do the same thing by pulling from GIT comments and adding the revision number

* Implemented mysqldump-lvm provider [GIT Source Revision #xyz]

*shrug*

I like this idea though it may need be something we better track moving forward (post 1.0).

> --
> WIKI: http://wiki.hollandbackup.org
> CODE: http://github.com/holland-backup
> UNSUBSCRIBE: holland-deve...@googlegroups.com
>

[BJ Dierkes]

On Jul 1, 2010, at 2:12 PM, Tim Soderstrom wrote:

> I am a fan of release notes myself. I think perhaps leveraging GIT issues might be a good thing here so we can do something like:
>
> * Implemented mysqldump-lvm provider [GIT Issue #xyz]
>
> Or perhaps for standard commits, do the same thing by pulling from GIT comments and adding the revision number
>
> * Implemented mysqldump-lvm provider [GIT Source Revision #xyz]
>

We are [or should be] already logging git commits in this fashion. Assuming the git history is accurate, we just need to pull out the relevant logs... and format it in a nicer way. But I can't do that when I have no idea where '0.9.9' was started (after 0.9.8) release.

---
derks

[Tim Soderstrom]

Yeah the branch/tagging concept has been blurred a bit since using GIT. I suspect post 1.0 we will branch out and have a 1.0 branch as well as our current dev branch. Doing that will likely make these things easier. For now, I don't know if we can easily pull the 0.9.8 -> 0.9.9 line of demarcation other than to know when we started implementing the 0.9.9 features (which started with the backup-set / USE flag changes I believe.

[Andrew Garner]

http://andreasjacobsen.com/2008/10/01/use-git-tags/

~Andy