Proper way to use versions and milestones

Wha开发者_运维知识库t's the intended purpose of versions and milestones in Trac? How to use them? How is milestone different from version?

---

A good way to illustrate the difference is to think of a defect ticket. When you file the ticket, you (the ticket submitter) use the version field to indicate the version of the software that exhibits the defect. Once the software maintainer triages the ticket, they assign it to a milestone that indicates the time frame in which the defect will be fixed. The ticket can be re-assigned from one milestone to another depending on project schedule, but the version number will remain the same. Version numbers refer to things that have already been released, and milestones refer to things that are in development or planned for the future and not yet started.

Some projects have a 1:1 mapping between versions and milestones. For example, the Trac project itself has a milestone for releases 0.12.3, 0.13, 0.14, etc. They also have more abstract milestones that don't map to a particular release, such as "next-major-0.1X" (which indicates whatever the next major release happens to be), "not applicable", and "unscheduled". When you go to create a ticket, though, the only things listed in the "Version" field are released versions and versions under active development.

Your milestones don't have to correlate to your versions in any way if you don't want them to. For example, you can create milestones for "october-2011", "november-2011", etc and use them for scheduling tasks to work on each month. It's completely up to you and the needs of your particular project.

---

The workflow goes something like this:

• You have tickets, that can be requests for new features, bug fixes, improvements, etc
• Then you decide which tickets have higher priority (based on maybe what the users need or how critical is a bugfix, etc).
• To organize the work (and the developers involved), you can state something like "a milestone will be 2 weeks long" (could be more, could be less, it's up to you)
• Then, you can estimate how many of those tickets can be actually solved in that amount of time (1 milestone).
• Then, you can release a new version every some amount of milestones (i.e: a public release after 1 or 2-4 milestones, unless something critical needs to be fixed).

To sum up, versions are intended to be full working releases (either public or not). And milestones are the roadmap to those versions. Tickets are the minimum unit of work that can be done in every one of those milestones.

---

Versions generally are more for releases to the users.

Milestones are more for steps that need to be accomplished in development. The users doesn't see or need to be aware of them. Some dev shops treat these as sub-versions (1.3.2a) that will be summed up to a released version (1.3.2).

There's a good discussion of that here.