Proper way to use versions and milestones

Question

What's the intended purpose of versions and milestones in Trac? How to use them? How is milestone different from version?

Answer 1

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.

Answer 2

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.