Welcome to the FogBugz Knowledge Exchange

Question

6

Hi all,

With the restriction of not being able to have release notes for cases that are not marked resolved (FogCreek has a case open: Case FC584149), I'm wondering how people are doing release notes?

I find that we should be able to attach release notes to any case, no matter what their status is, and because of the limitation, we're having to workaround it by creating sub-cases and tags which I feel that there may be easier ways that we haven't thought of.

Could you share your release notes process?

Thanks

edited Oct 18 2010 at 13:10

adambox♦♦
23.9k●1●22●63

asked Aug 1 2010 at 6:35

Totem
169●4

Could you share your release notes process? Perhaps if you provided an example we might better understand what it is you're trying to do. To me, it doesn't make sense to include release notes on unresolved cases. Typically release notes consist of bug fixes and feature implementation. If your bug has not been Resolved (Fixed) or your feature has not been Resolved (Implemented) why would you want to include information about that case in your release notes? – Greg Saven♦ Aug 1 2010 at 19:44

Think about the times when you want to notify the user of an issue that will not be fixed but the product is going out with it. The case (bug in many cases) is not marked as resolved in any way so there's no way in FB to add the release note comment. We do not want to mark them as any other resolution, because the case is still open and needs to be addressed (possibly in the next sprint or future sprints). – Totem Aug 2 2010 at 5:41

We occasionally have to release additional diagnostic tools to track down obscure problems, so I consider this a legitimate question. We do not, however, use FogBugz for release notes; they are managed in our change control system rather than our defect tracking system. – James McLeod♦ Aug 2 2010 at 11:48

1

What about setting the status of these cases to Resolved (Postponed) (or you can define your own status with the Workflow plugin)? – Greg Saven♦ Aug 2 2010 at 13:10

The developer who fixed the bug might want to add a release note. Perhaps to provide some information how to use a new feature or recover from the bug solved. You might want to give this information to the user deciding to close the case. The cases may be closed (perhaps automatically) after passing a big test suite. There are plenty of use cases for Release Notes being entered on open cases. – Uwe Raabe Sep 23 2010 at 6:07

Julian Melville · Answer 1 · 2010-09-22 23:13:55Z UTC

We've added custom fields for release version and release note, and query them using the version number when a release goes out. There's a little bit of intervention required to make sure all the right stuff goes in there, but it works fine for our small team. Having to wait until the case is closed would not work for us.

chris · Answer 2 · 2010-09-22 22:20:01Z UTC

I find myself closing the case to make a note, then reopening it, which is a total pain. I can see some work flows not adding a release not until the task was complete, but I think making the link unavailable is just a silly imposition on those who, like me, may want to add a note while I am in the middle of working on something and want to make a note on it before I forget.

Stephen C. Steel · Answer 3 · 2010-09-23 19:25:33Z UTC

Right now, the release notes field is a peculiar variant of a required field: it is required to be blank unless the case is marked as resolved.

Almost everything the FogBugz team has written about required fields being evil applies equally well to this case. The FogBugz staff should re-read some of their arguments against required fields with this in mind and seriously rethink why they feel they need to prohibit users from entering information in the release notes before a case is resolved just because it wouldn't make sense to them.

The current policy vaguely makes sense for software projects, but only if you think that resolving a Fogbugz case corresponds to checking source code changes in to the revision control system. But, even restricting ourselves to using FogBugz with software projects, there are lots of reasons why release notes might be useful before the case gets to be marked as resolved:

We might want to review the source code changes before a case is marked as resolved.
We might want to review the release notes themselves before a case is resolved.
We may need to merge the source code changes into the main trunk in our version control system before a case is resolved.
We may need to include the changes in a version of the software that is released to customers before a case is resolved.
We may require that the customer that raised the bug report confirm the new version does indeed fix the problem that caused them to raise the bug before it resolved.

How are you creating/maintaining release notes with FogBugz?

3 Answers