Redmine

Considering how simple it is to copy the issue and reassign the milestone, I can't see the benefit of multiple milestones. From a user perspective there might be one extra mouse click.

Since you specifically state that internally it "would be seen as several issues" I think it's much clearer and cleaner to make it in fact multiple issues using the copy mechanism.

Setting a relation between the two issues means the original bug information is just a click away. It's quick and easy, and fixing a bug for a release vs. development is actually two different operations, and so really should be two different issues.

the dissadvantages when copying are:

• you can't see when you are looking a an issue, in which versions it is fixed.
  --> loss of overview
• you need to know several issueIDs when checking in the fix for an issue and you want to include hat in the committext
  --> again, loss of overview, especially when looking a your commit-messages. you have to check all issue#s
• when you have more than 2 target milestones, it is more work to copy an issue and set it to the different milestones!
  --> and even more clicks
• if you have to change the primary message because the reported error is different than the actual error, you have to
  write this in every copyed issue....
  --> more work, more klicks

--> generally, it would be nice to see, if every fix of SP2 made it into the next stable-version... this would be
possible in this case...

To start with, this is a duplicate of issue #284. I even wrote a patch to implement this behaviour (see #219); however, there is no way that this patch would cleanly apply anymore - things have changed far too much since then. There is also a forum post that is asking these same questions, and finding issue duplication to be a "long and annoying procedure".

Considering how simple it is to copy the issue and reassign the milestone, I can't see the benefit of multiple milestones. From a user perspective there might be one extra mouse click.

Duplication of this kind of data is just plain wrong. Updating one ticket would now mean updating the other 4 tickets (for example), but how does the user know which other issues to update unless a whole bunch of issue relations were created in the first place? Even then, is the user really going to remember? In our organisation, issues get handed back and forth with extra information being added all the time. It's just not feasible to have multiple issues for the same "issue".

There is most definitely a case for being able to specify multiple targets for an issue, but in my case, we do not require that issues get marked as fixed in one target or another. If we have an issue that needs fixing in 3 branches, we use the Refs commit keyword for the first two, then Fixes for the last one. We do not need an automatic progress update or commit messages such as #1234m3. Our target names are not really suitable for putting into a commit message like that last example - they are long, contain white space, etc...

All we need is to say an issue is part of multiple targets so that they show up in each target's roadmap, etc. You can see a brief overview of the workflow that my company utilises in #284. Currently, writing release notes for a version is far too difficult - if an issue is fixed in version 2.1 and 1.1, the issue is currently marked as an issue in r1.1 with a note for fixing also in 2.1. Listing the issues for 2.1 does not show the issues that were fixed yet marked for 1.1.

Another place in our organisation where Redmine is not quite there yet, is how our QA team mark that an issue has been fixed in one version, but remains untested in another version. The only way I can think this would be workable though is actually having an issue per target to facilitate this need for having a different status in each target. I don't like the idea at all, but I don't know how to answer this problem at the moment either :)

We are creating "link-issues" per branch/version (almost like sub-issues) to keep track.

We do NOT want to copy issue since comments/updates in one branch can be critical information for another branch's update (usually some weeks/months later). The bad side of link issues is the loss of good overview on roadmap/issue summary pages. Cut/Paste of subject works as long as no branch-team changes/clarifies it. Metrics/summary are partly lost (we cannot keep link-issues as a specific tracker since we use different workflows in different branches/versions (different rules when changing a live version compared to a untested/future release)). We can tell metris per version/branch but not unique issues for the whole system.

Perfect solution would be some special lightweight link-issues with a subset of attributes (maybe their own workflow, status, timetracking and perhaps branch-local-comments) but with all other fields/comments linked back to main issue. Perhaps some way to close top-issue when all sub-issues are closed.

/T

+1

I'm strongly again: Milestones are often used also for non-spftware purpose. If you assign more than one milestone to single ticket, time tracking will be in big trouble, because spent time of single ticket will be calculated two (or more) times to different versions resulting in wring time and price calculations which is critical.

For example, we're using milestones for different blocks of project and we're billing milestones to our clients separately.

Maxim Krušina wrote:

I'm strongly again: Milestones are often used also for non-software purpose. If you assign more than one milestone to single ticket, time tracking will be in big trouble, because spent time of single ticket will be calculated two (or more) times to different versions resulting in wring time and price calculations which is critical.

For example, we're using milestones for different blocks of project and we're billing milestones to our clients separately.

And that is fine - you would simply continue to not use multiple milestones for your work. The situation in other companies requires multiple milestones/versions/branches/releases per issue in order to track changes. I would suggest a setting for showing a single or multiple selection control for the issue version.

Isnt this another issue that could be solved with subissues (se #443), each issue having their own status, target version and everything else useful. Timekeeping isnt the only problem with multiple milestones. How to know what if some step has been done for a specific branch(future version)?

/T

I don't need subtask as I don't need Timetracking for all different Milestones..
When I solve a task for one branch, I just have to merge the code to the other branch.... so timetracking is not always needed...
I just need to document if I merged the change in both branches or if I forgot....
So, adding a second target-milestone the same way as adding a new watcher would be the best solution for me. Internally,
the 2nd. Milestone could be a 1:1 copy of the main ticket with only 2 seperate fields: It needs its own Milestone And its own Solution..

is there a way to vote for issues in this redmine?
We really need this "multiple target" feature. we have several branches and need to enforce the process somehow that bugs need to be fixed in all of them before marking as "resolved/closed".

Been a while, but I'd like to +1 this. I may implement it myself locally.

In general multiselect switch feature should be possible for all fields, also custom fields of type list or enumeration.