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