https://www.redmine.org/https://www.redmine.org/favicon.ico?16793021292008-05-20T18:43:17ZRedmineRedmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=28472008-05-20T18:43:17ZCarl Nygard
<ul></ul><p>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.</p>
<p>Since you specifically state that internally it "would be seen as several issues" I think it's much clearer and cleaner to make it <strong>in fact</strong> multiple issues using the copy mechanism.</p>
<p>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 <strong>should</strong> be two different issues.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=28492008-05-20T19:52:16ZSepp _
<ul></ul><p>the dissadvantages when copying are:</p>
<ul>
<li>you can't see when you are looking a an issue, in which versions it is fixed.<br /> --> loss of overview</li>
<li>you need to know several issueIDs when checking in the fix for an issue and you want to include hat in the committext<br /> --> again, loss of overview, especially when looking a your commit-messages. you have to check all issue#s</li>
<li>when you have more than 2 target milestones, it is more work to copy an issue and set it to the different milestones!<br /> --> and even more clicks</li>
<li>if you have to change the primary message because the reported error is different than the actual error, you have to <br /> write this in every copyed issue....<br /> --> more work, more klicks</li>
</ul>
<p>--> generally, it would be nice to see, if every fix of SP2 made it into the next stable-version... this would be <br /> possible in this case...</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=28532008-05-20T21:46:13ZAnonymous
<ul></ul><p>To start with, this is a duplicate of issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Issues fixed in multiple versions (Closed)" href="https://www.redmine.org/issues/284">#284</a>. I even wrote a patch to implement this behaviour (see <a class="issue tracker-3 status-1 priority-4 priority-default" title="Patch: Issues fixed in multiple versions (New)" href="https://www.redmine.org/issues/219">#219</a>); however, there is no way that this patch would cleanly apply anymore - things have changed far too much since then. There is also a <a href="http://www.redmine.org/boards/2/topics/show/386" class="external">forum post</a> that is asking these same questions, and finding issue duplication to be a "long and annoying procedure".</p>
<blockquote>
<p><em>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.</em></p>
</blockquote>
<p>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".</p>
<p>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...</p>
<p>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 <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Issues fixed in multiple versions (Closed)" href="https://www.redmine.org/issues/284">#284</a>. 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.</p>
<p>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 :)</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=43872008-08-15T22:44:27ZThomas Pihl
<ul></ul><p>We are creating "link-issues" per branch/version (almost like sub-issues) to keep track.</p>
<p>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.</p>
<p>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.</p>
<p>/T</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=55322008-11-11T09:36:35ZJean-Philippe Langjp_lang@yahoo.fr
<ul><li><strong>Target version</strong> deleted (<del><i>0.8</i></del>)</li></ul> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=66642009-01-14T00:20:41ZReach Everywhere
<ul></ul><p>+1</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=66662009-01-14T08:41:55ZMaxim Krušina
<ul></ul><p>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.</p>
<p>For example, we're using milestones for different blocks of project and we're billing milestones to our clients separately.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=66682009-01-14T10:53:06ZAnonymous
<ul></ul><p>Maxim Krušina wrote:</p>
<blockquote>
<p>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.</p>
<p>For example, we're using milestones for different blocks of project and we're billing milestones to our clients separately.</p>
</blockquote>
<p>And that is fine - you would simply continue to not use multiple milestones for your work. The situation in other companies <strong>requires</strong> 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.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=71402009-02-05T10:30:51ZThomas Pihl
<ul></ul><p>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)?</p>
<p>/T</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=71652009-02-06T09:29:52ZSepp _
<ul></ul><p>I don't need subtask as I don't need Timetracking for all different Milestones..<br />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...<br />I just need to document if I merged the change in both branches or if I forgot....<br />So, adding a second target-milestone the same way as adding a new watcher would be the best solution for me. Internally,<br />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..</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=120012009-11-11T23:47:55ZAlex Last
<ul></ul><p>is there a way to vote for issues in this redmine? <br />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".</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=138172010-01-25T17:45:22ZRocco Stanzione
<ul></ul><p>Been a while, but I'd like to +1 this. I may implement it myself locally.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=310062011-07-23T09:22:03ZTerence Mill
<ul></ul><p>In general multiselect switch feature should be possible for all fields, also custom fields of type list or enumeration.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=486612013-04-16T10:08:17ZToshi MARUYAMA
<ul><li><strong>Category</strong> changed from <i>Issues</i> to <i>Roadmap</i></li></ul> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=500122013-06-11T18:11:41ZJoel SCHAAL
<ul></ul><p>Ok so I added "my vote" to <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Allow multiple target versions (Closed)" href="https://www.redmine.org/issues/5272">#5272</a>, which was marked as duplicate of this one.<br />But my remarks are still the same :</p>
<blockquote>
<p>It has been entered more than <del>2</del> 5 years (!!) ago and it is still new.<br />Is this a rejected issue ?<br />Does this issue depend on other work ?<br />Can we have some update on what will be decided for this task ?</p>
</blockquote>
<p>Thank you.</p>
<p>Edit : The discussion <em><a class="message" href="https://www.redmine.org/boards/1/topics/214">Versions vs Milestones</a></em> could be related to this issue.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=528952013-10-31T08:33:34ZKetki Vahalia
<ul></ul><p>+1<br />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!</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=529192013-11-01T13:06:41ZMichaël de Groot
<ul></ul><p>+1.</p>
<p>We have several live versions running of a project. 1 issue unfortunately may be fixed in several versions.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=547172014-02-07T20:30:35ZAlcides Silveira Costa
<ul></ul><p>+1</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=566832014-06-09T13:48:53ZNatanael Copa
<ul></ul><p>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.</p>
<p>I would <strong>love</strong> 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.</p>
<p>Thanks!</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=575672014-07-16T09:18:50ZAlice Etchegaray
<ul></ul><p>+1</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=578152014-07-30T15:45:00ZDavid Fouche
<ul></ul><p>+1</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=581762014-08-19T18:42:04ZDomingo Galdos
<ul></ul><p>+1</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=600392014-11-27T10:22:38ZToni Smillie
<ul></ul><p>I really need this too - please prioritize it for upcoming version</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=604342014-12-17T12:51:49ZEduardo Lima Fabricio
<ul></ul><p>+1 .. I need this too !</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=634852015-05-01T19:26:19ZTodd Van Allen
<ul></ul><p>This is a very vital feature for organizations with multiple releases to manage.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=661322015-09-22T14:33:13ZRicard F
<ul></ul><p>+1000!!</p>
<p>Vital feature!</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=661442015-09-23T11:08:02Zbudo kaiman
<ul></ul><p>+1</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=661482015-09-23T15:32:46ZTodd Van Allen
<ul></ul><p>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.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=661492015-09-23T15:37:09ZSepp _
<ul></ul><p>Todd Van Allen wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=661502015-09-23T16:00:15ZTodd Van Allen
<ul></ul><p>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.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=724482016-07-27T20:29:19ZMark Wintch
<ul></ul><p>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.</p>
<p>Thank you.</p>
<p>Environment:<br /> Redmine version 3.3.0.stable<br /> Ruby version 2.1.8-p440 (2015-12-16) [x64-mingw32]<br /> Rails version 4.2.6<br /> Environment production<br /> Database adapter SQLServer<br />SCM:<br /> Filesystem <br />Redmine plugins:<br /> redmine_agile 1.4.1</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=809442017-09-05T10:53:30ZDavid LECLERCQ
<ul></ul><p>I think too, it's a vital feature.</p>
<p>When can be realised this feature ?</p>
<p>Thanks</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=860872018-07-06T06:30:51ZEdgars Batna
<ul></ul><p>+100<br />This should be somewhere on the Roadmap, as managing simultaneous maintenance and development teams is currently a pain.</p>
<p>It is not so much about creating tickets per version as the absolutely retarded usability that comes with it. We need a solution to stop copying information around and have a usable view about ONE ISSUE that has sub-issues per version, which does not increase our blood pressure.</p>
<p>Should be some sort of inheritance of properties or fields and a sensible view for such "target version subtickets". I'm sure there is a technical solution to this.</p>
<p>Plus, if one looks at the Roadmap, there's so many useless, low-level, unimportant technical things getting changed, yet the elephant remains.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=988402020-08-17T02:05:21ZQiang Gao
<ul></ul><p>It seems this feature hasn't been done yet, it's 13 years and I think it's harder and harder to add this feature since it would change the design of Redmine, what a pity</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=989412020-08-26T09:17:07ZMarco Shima
<ul></ul><p>We are also missing this feature. Actually there is no feature we're missing more at the moment.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=1028742021-06-18T11:38:32ZMark Tomm
<ul></ul><p>+1</p>
<p>This is a must have for non-weekend projects which span multiple OS and architectures.</p> Redmine - Feature #1266: Feature: Allow setting multiple target-milestoneshttps://www.redmine.org/issues/1266?journal_id=1129742024-02-21T05:02:07ZMarco Shima
<ul></ul><p>Mark Tomm wrote in <a href="#note-36">#note-36</a>:</p>
<blockquote>
<p>+1</p>
<p>This is a must have for non-weekend projects which span multiple OS and architectures.</p>
</blockquote>
<p>Exactly my opinion.</p>