Each project in FogBugz can have a list of releases.
For example, each major version of your software is a release, whatever numbering scheme you use:
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:
Each milestone has a date; for example, the 2.0 Beta release might be planned for 2/28/2005. You can move the date at will (although your management may be less flexible than FogBugz about changing dates!)
You can set up the list of releases by editing the project. Once you've set up releases for a project, every case in that project can be assigned to a particular release for which you plan to fix this bug or implement this feature. This is sometimes called the "Fix For" of the case.
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.
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, for example, "When Pigs Fly" or "Undecided" or "ASAP".
Although releases are normally per-project, you can also create releases that are usable with any project. When you do this, cases in any project can be assigned to that release. For example, some development teams may rerelease all their software every month. FogBugz ships with "Undecided" as a useful default release. You can also use global releases when there is an event coming up by which time certain bugs need to be fixed in a bunch of projects. To edit these global releases, go into any project.
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 bugs.
