Comments on: How Do You Maintain Your Change Log? http://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/ Living in a state of accord. Tue, 07 Feb 2012 01:07:58 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Rob Dawsonhttp://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/comment-page-1/#comment-35358 Rob Dawson Wed, 18 Oct 2006 13:32:10 +0000 http://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/#comment-35358 I'd add a vote to Doug's plan, keeping the file up to date when ticking off story cards would work well. Perhaps making updating the file part of the reward for finishing off a story would be nice. Given that story cards are the way of tracking work (if JIRA was how this was done, things would change), then this would be a good strategy to try. Moving the bug fixes to story cards would be a good approach to follow as well. As already suggested, the idea of including the bug fixes in the mix of story cards would help this process, and might also help tracking velocity. I’d add a vote to Doug’s plan, keeping the file up to date when ticking off story cards would work well. Perhaps making updating the file part of the reward for finishing off a story would be nice.

Given that story cards are the way of tracking work (if JIRA was how this was done, things would change), then this would be a good strategy to try.

Moving the bug fixes to story cards would be a good approach to follow as well. As already suggested, the idea of including the bug fixes in the mix of story cards would help this process, and might also help tracking velocity.

]]> By: Adrian Suttonhttp://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/comment-page-1/#comment-35150 Adrian Sutton Tue, 17 Oct 2006 12:01:17 +0000 http://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/#comment-35150 Because not all check-ins should be reported to end users. A subversion hook, or a log command, is one option we've looked at but since not all check-ins should be reported it requires discipline to make sure the specific format is followed. We've also found that as developers we like to have our commit comments describe what we changed in the code, not what the user needs to identify what changed. I'd like to find a process that fits in with the way we work without making us contemplate the change log all the time. Because not all check-ins should be reported to end users. A subversion hook, or a log command, is one option we’ve looked at but since not all check-ins should be reported it requires discipline to make sure the specific format is followed. We’ve also found that as developers we like to have our commit comments describe what we changed in the code, not what the user needs to identify what changed. I’d like to find a process that fits in with the way we work without making us contemplate the change log all the time.

]]> By: Greg Blackhttp://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/comment-page-1/#comment-35143 Greg Black Tue, 17 Oct 2006 10:48:19 +0000 http://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/#comment-35143 Why not just use a subversion hook script to log the commit message on each checkin? Why not just use a subversion hook script to log the commit message on each checkin?

]]> By: Adrian Suttonhttp://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/comment-page-1/#comment-35072 Adrian Sutton Mon, 16 Oct 2006 21:21:42 +0000 http://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/#comment-35072 There are a couple of problems with just using an automated report from a bug tracking tool: 1. Not all changes to the product are because of bugs. We add new features too. :) Our features are tracked on story cards so that we can pass them around and physically see our progress through the iteration. It's working really well and I'm not keen to change it. We also have a public facing support system that occasionally requires bug fixes and we don't want the overhead of having to log the issue in the bug tracking system when it's already documented in our support system. 2. Not all bug fixes need to be included in the change logs. During a release we quite often find bugs in the new features which have never been released to clients. It would be silly to have a bunch of entries in the change log reporting that we fixed problems that no user could possibly have ever seen. We're also quite happy with bugzilla for now and the ultimate aim is to get rid of the existing back log of bugs and ditch bug tracking systems altogether. Instead whenever we find a bug it will be fixed immediately and short of that, written on a story card and scheduled like any other work. There are a couple of problems with just using an automated report from a bug tracking tool:
1. Not all changes to the product are because of bugs. We add new features too. :) Our features are tracked on story cards so that we can pass them around and physically see our progress through the iteration. It’s working really well and I’m not keen to change it. We also have a public facing support system that occasionally requires bug fixes and we don’t want the overhead of having to log the issue in the bug tracking system when it’s already documented in our support system.

2. Not all bug fixes need to be included in the change logs. During a release we quite often find bugs in the new features which have never been released to clients. It would be silly to have a bunch of entries in the change log reporting that we fixed problems that no user could possibly have ever seen.

We’re also quite happy with bugzilla for now and the ultimate aim is to get rid of the existing back log of bugs and ditch bug tracking systems altogether. Instead whenever we find a bug it will be fixed immediately and short of that, written on a story card and scheduled like any other work.

]]> By: Niallhttp://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/comment-page-1/#comment-35040 Niall Mon, 16 Oct 2006 15:19:34 +0000 http://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/#comment-35040 Switch to JIRA - it will generate release notes for you, as long as your disciplined about the fix version number. Switch to JIRA – it will generate release notes for you, as long as your disciplined about the fix version number.

]]> By: Yoav Shapirahttp://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/comment-page-1/#comment-35038 Yoav Shapira Mon, 16 Oct 2006 14:14:47 +0000 http://www.symphonious.net/2006/10/16/how-do-you-maintain-your-change-log/#comment-35038 On projects I participate in, we're closer to the XP approach but not quite. The changelog is a file in our source code control system, with a section for each release -- very simple. Every time a developer addresses an issue, he or she updates the change log with what they've done. If the issue was in our issue tracker, the developer adds a link as relevant. That's it. The change log is always (or almost always, as humans are imperfect) up to date in SVN. The release manager has little to no work to do when cutting the release. On projects I participate in, we’re closer to the XP approach but not quite. The changelog is a file in our source code control system, with a section for each release — very simple. Every time a developer addresses an issue, he or she updates the change log with what they’ve done. If the issue was in our issue tracker, the developer adds a link as relevant. That’s it. The change log is always (or almost always, as humans are imperfect) up to date in SVN. The release manager has little to no work to do when cutting the release.

]]>