Feature #1266

Feature: Allow setting multiple target-milestones

Added by Sepp _ over 9 years ago. Updated about 1 month ago.

Status:NewStart date:2008-05-20
Priority:HighDue date:
Assignee:-% Done:

0%

Category:Roadmap
Target version:-
Resolution:

Description

this is needed when we discover a bug and it needs to be fixed in the stable branch and in the development-branch....
It is difficult and not very much the desired resultto copy each issue for each milestone...

I think, the issue could internally be seen as "several issues"...., like #1234m1 for milestone 1??
When it gets fixed for milestone #1, i'd like to set milestone one as fixed. If i search all tickets for milestone 2,
this issue should still show up and should not be seen as fixed. Maybe it would be nice to see it 95% fixed, so i know, that you just have tu merge the code and test it....

what do you think?


Related issues

Related to Redmine - Feature #1675: Add 'affected version' as a standard field Closed 2008-07-23
Related to Redmine - Patch #219: Issues fixed in multiple versions New
Related to Redmine - Patch #5510: Enable Mutliple Versions Per Issue Resolved 2010-05-12
Duplicated by Redmine - Feature #5272: Allow multiple target versions Closed 2010-04-08

History

#1 Updated by Carl Nygard over 9 years ago

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.

#2 Updated by Sepp _ over 9 years ago

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...

#3 Updated by Nick Read over 9 years ago

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 :)

#4 Updated by Thomas Pihl about 9 years ago

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

#5 Updated by Jean-Philippe Lang almost 9 years ago

  • Target version deleted (0.8)

#6 Updated by Reach Everywhere almost 9 years ago

+1

#7 Updated by Maxim Krušina almost 9 years ago

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.

#8 Updated by Nick Read almost 9 years ago

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.

#9 Updated by Thomas Pihl over 8 years ago

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

#10 Updated by Sepp _ over 8 years ago

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..

#11 Updated by Alex Last almost 8 years ago

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".

#12 Updated by Rocco Stanzione over 7 years ago

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

#13 Updated by Terence Mill about 6 years ago

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

#14 Updated by Toshi MARUYAMA over 4 years ago

  • Category changed from Issues to Roadmap

#15 Updated by Joel SCHAAL over 4 years ago

Ok so I added "my vote" to #5272, which was marked as duplicate of this one.
But my remarks are still the same :

It has been entered more than 2 5 years (!!) ago and it is still new.
Is this a rejected issue ?
Does this issue depend on other work ?
Can we have some update on what will be decided for this task ?

Thank you.

Edit : The discussion Versions vs Milestones could be related to this issue.

#16 Updated by Ketki Vahalia almost 4 years ago

+1
In our case, we track issues by customer versions and also by server patch versions. Making a copy and remembering the relations is needless overhead for developers. There should be a clean way to accomplish the need of associating an issue with multiple versions. Thanks!

#17 Updated by Michaël de Groot almost 4 years ago

+1.

We have several live versions running of a project. 1 issue unfortunately may be fixed in several versions.

#19 Updated by Natanael Copa over 3 years ago

We (alpine linux) are currently creating multiple issues to track security bugs in all our 4 stable branches. It means that for each security issue we create normally 5 issues (one tracker issue and one for each branch). With 5 issues (a normal week) this becomes 25 issues and much time goes to simply create and close those tickets.

I would love beeing able to only create one ticket for each security issue (which after all are same issue) and simply mark which git branches needs to be fixed instead of making 5 copies of same thing. It would make our lives much easier.

Thanks!

#20 Updated by Alice Etchegaray over 3 years ago

+1

#21 Updated by David Fouche about 3 years ago

+1

#22 Updated by Domingo Galdos about 3 years ago

+1

#23 Updated by Toni Smillie almost 3 years ago

I really need this too - please prioritize it for upcoming version

#24 Updated by Eduardo Lima Fabricio almost 3 years ago

+1 .. I need this too !

#25 Updated by Todd Van Allen over 2 years ago

This is a very vital feature for organizations with multiple releases to manage.

#26 Updated by Ricard F about 2 years ago

+1000!!

Vital feature!

#27 Updated by budo kaiman about 2 years ago

+1

#28 Updated by Todd Van Allen about 2 years ago

I'm guessing the reason that this feature (which is pretty key) is not getting much traction as the work-around is creating your own custom field (e.g. 'Targeted for Versions') and using that. But this creates two such fields in the UI which is confusing. A Key field like this one should be multi-select.

#29 Updated by Sepp _ about 2 years ago

Todd Van Allen wrote:

I'm guessing the reason that this feature (which is pretty key) is not getting much traction as the work-around is creating your own custom field (e.g. 'Targeted for Versions') and using that.

Not only. Every 'Targeted for Versions' hat its own status, so it might be fixed in version 3.0, but is still open in version 2.0.

#30 Updated by Todd Van Allen about 2 years ago

The hack that we use is the addition of two other fields; 'Affects Versions' and 'Fixed in Versions'. This tracks the versions that the application is broken in and which versions it's been fixed in. The delta between these two fields provides the 'Known Issues' for a particular release. It's an ugly hack with a lot of overhead, but it's functional at this point. Until, of course, they add this feature to the application.

#31 Updated by Mark Wintch about 1 year ago

As of today in this environment I am not able to perform this function. We have also purchased the RedmineCRM Agile plugin which does not allow multiple target versions to be selected. I will also follow up with that group, however this seems a good place to request this feature be implemented in Redmine as with the 3.3.0 release I still am unable to do it. Are any others getting this done? I do not want to do a work around, however please explain it if you can as we need some way of implementing this feature to the greatest extent possible.

Thank you.

Environment:
Redmine version 3.3.0.stable
Ruby version 2.1.8-p440 (2015-12-16) [x64-mingw32]
Rails version 4.2.6
Environment production
Database adapter SQLServer
SCM:
Filesystem
Redmine plugins:
redmine_agile 1.4.1

#32 Updated by David LECLERCQ about 1 month ago

I think too, it's a vital feature.

When can be realised this feature ?

Thanks

Also available in: Atom PDF