Releases

For each feature in FogBugz, you have to decide when you want to implement it. Similarly, for each bug, you have to decide when it's going to be fixed.

In FogBugz this is done by assigning the case to a particular release. This is called the "Fix for" of the case.

For example, each major version of your software is a release, whatever numbering scheme you use: 1.0, 2.0, etc.

(Or, if you're insane, you can use a simple and obvious numbering system like 1.0, 2.0, 286, 386, 3.0, 3.1, 3.11, 95, 98, 98SE, Me, XP, ...)

Minor versions will also have releases. For example, a typical software project might have milestones of Alpha, Beta 1, Beta 2, Release Candidate, Gold Release, Service Pack 1, etc.

You can also use releases for milestones in the code development process, like "Search feature code complete" or "Performance work and optimizations".

When a certain release is coming up, you can create a filter to see all the features and bugs that need to be fixed for that release.

To edit releases, you have to be an administrator. From the Settings menu, choose Projects. Click on the project name and scroll down where you'll see a section marked Releases (this project).

Each milestone has a date; for example, the 2.0 alpha release might be planned for 6/4/2007. You can move the date at will (although your management may be less flexible than FogBugz about changing dates!)

• Note that your "official" dates that you enter for a release are not the same as the dates that FogBugz will calculate later using Evidence-Based Scheduling. As far as EBS is concerned, the only thing that matters about official dates is their order. It will assume that you're going to do all the "search feature milestone" stuff before you do any of the "alpha" stuff because it comes first, officially. But EBS will have it's own opinions of when you're going to finish, based on your estimates, not based on the official date.

When you fix a bug or implement a new feature, before you resolve the case, double check that the Fix For is correct; that way it can also be used as an historical record of which bugs were fixed in which release, and which new features were implemented for which release.

FogBugz also lets you maintain and create Release Notes automatically. See Release Notes.

You can also create meaningful releases without dates.

Although releases are normally per-project, you can also create releases that can be used for any project. FogBugz ships with "Undecided" as a useful default release. You may also want to add "ASAP" or "Never".  To edit these global releases, go to the Settings menu and choose Projects. Click on any project name and scroll down where you'll see a section marked "Releases (all projects)".

After a release has already shipped, it doesn't make any sense to assign new cases to it. You should set the "Assignable" field of the release to "No" to prevent new cases being assigned to a release that has already shipped, which also makes the "Fix For" dropdown shorter so it's easier to enter new cases.