Redmine

What functionality is different between versions and milestones? How does Trac differentiate them?

For example, you have SomeApp in version 1.0 and 1.1 and now you are working on 2.0.
It's bigger púroject, so you have to divide development into phases - milestones. You need to have deadline for each milestone, and you need to track how much work is done in each milestone, so you can track both nr of issues open/solved per milestone and time estimated/done/remining.

Versions are reserved relly for SW versions. Also, versions are in tickets when reporting bugs, because you need to track in which version was bug found, in which version you would like to fix it and actually, in which version it was fixed.

I see what you are saying. However, i don't see how you couldn't just use "versions" for this as well. Or sub-projects, one for each milestone. Could you not create a version for each milestone? 1.0.1, 1.0.2 ... and so on? You could still assign tickets (issues) for each thing that needs to be done (script or document written) to a version, which can be given a date, and think of it as a milestone. I'm not arguing for not having milestones, i'm just trying to see if there is a way to get most of what you want using the current tool.

Hope you don't mind my jumping in here but I also tend to favour the name change from Version to Milestone.

I understand both sides of the argument but I think something as simple as changing the word from Version to Milestone would help a lot.
Milestones are more generic and opens up Redmine to a new set of users who are not involved with managing software projects. I personally use it to manage software and non-software projects and feel the term Version is a misnomer when applied to non-software projects.

Along the same lines, but slightly off topic, is the concept of iterations. In agile software development, iterations are used frequently and I do not see how to apply this concept in Redmine. Therefore, I think it would be very useful to add support for Iterations in Redmine. In my view, it would take several iterations to complete a Milestone. To simplify these combined changes, one could treat Milestones as a container for Versions (where Versions could then become synonymous with iterations).

I've not added this as an official request because I'd like to see what others think of this idea first and maybe have it fleshed out here through discussions first.

First of all, i'm all for changing "versions" to "milestones". That seems like an easy win.

That said, i still don't understand why one can't create a series of smaller milestones? Why do you need a hierarchical grouping of milestones? If i were doing Scrumm or Agile dev, once you've come up with the changes for the current "iteration", create a new milestone, and assign tickets with the needed changes to that milestone. Why do you need "smaller" units of work? The real question is, to quote Ronald:

"In agile software development, iterations are used frequently and I do not see how to apply this concept in Redmine."

What don't milestones get you that this "new" idea of iterations would? You don't really spell it out, what the functionality of "iterations" would be in redmine.

Here is an example of using Milestones/Versions to do what i hear you want to do (keeping in mind that i don't really have any idea what it is you want to do ;)

You want to get to milestone 1.0. You create point milestones for each iteration towards 1.0 - 0.1, 0.2 ... 0.2345. Or to use more English sounding milestones:

"Finished Project" - 1.0

Iterations to reach "Finished Project" - "Iteration Week 1", "Iteraction Week 2"...

I'm interested to hear more about this whole subject - keep up the discussion!

Will it be sufficient to have a dropdown box (when adding/editing a version) to define if this object will be called "Version", "Milestone" or "Iteration"?

And what about simillar solution like in Trac: there can be both Version and Milestone, but there are visible only when there are some milestones/versions defined, so for projects where are no milestones defined the look of issue will be same. Anyway, I think that it's better to have support for both versions and milestones at the same time rather that select for name. It's because we can have project with tho majour versions (1.0 and 2.0) but we need to plan some milestones to somplete project.

In my point of view, versions are really tighly bond to SW versions, so it's usefull for reporting in which version exactly was bug found or in which version we wopuld like to fix it. Milestones act just for organizational purposes, so it's not actually bond to exact version. One of milestone can be "Finish complete translation", but this milestone can be postponed etc, while mail development continues.

Maxim - what's keeping you from using Versions as a general organizational tool now? Yes, they can be tightly associated with a release/code, but they don't have to be. You can use them as a simple "all these things are related to this" tool.

It really just seems to be a difference in terms/language, rather then a difference in function. I've yet to read anyone detail what the functional difference, in redmine, would be between versions and milestones.

Sooo, any more discussion on this? Anyone? ;)

Errrg, I'm just using versions for mile-stoning now ;)
I still think that milestone is more descriptive term, but there are probably more important issues to solve now...
Again, thanx to all for great app!

Maybe it has to be configurable setting :)
If the functionality is the same, it's just a label.

You perfectly get my point: it's just a damn label :)

I recently went through the process of converting Version to Milestone, but found that the version label is also being used for document revisions. "Milestone" in that context doesn't make sense. When I upgrade to 0.7 I'll see about splitting this into different labels, and perhaps submitting a patch.

i would like to see both.

Example:

version 2.0 (3 Milestones), Version 2.5 (1 Milestone)

For finishing Version 2.0 there are a few milestones to finish before

Milestone1: planning
Milestone2. programming
Milestone3. beta testing

So if Milestone 1 is not reached its not possible to start/finish milestone2.

If Milestone2 needs to pushed back all following milestones and Versions are pushed back as well.

So you could see all open tasks for Version 2 (all Milestones) to finish or just the tasks for Version2/Milestone 2 to finish.

Tom,

No offense, but your example is a non-sens: every project is a heavy iterative process. So if you can't do anything in M2 if M1 is not ended, that means that you forbid to work again on M1 once you start M2. Hard blocking work on a milestone because an other set of milestones don't make sens: the better approach is to explain how you want user your tracker to your team rather to take technical restriction.

Tom,

Yes youre right, my explanation was weak ;)

Ok, ill try to make it more understandable:

1. See the Gantt-Project ... these relations would be very usefull (see demo)

2. To reach a version a few milestones are needed. A customer giving feedback knows about the version (version 1 is already in productive use, version 2 is the development), but for sure he cannot (and should not) target the milestones with his request.

So he can post a ticket to the correct version, the team decides to which milestone this ticket must be assigned.

Other example:

You build a website. following stages (milestones) for version 2.0

1. planning
2. programming of the backend
3. programming of the frontend
4. get content from customer
5. content into cms
6. beta
7. launch

Here some of the milestones can be started and worked on together independend (2 - 4), but 5 cannot be started bevore 2-4 are finished

What would be really helpfull would be a integration of the Gantt-project or similar functionality. So if one task needs longer all other timings get adjusted.

Usual szenario: you get needed data from your customer 1 week late. So you adjust and can hand him out the new timing schedule.