https://www.redmine.org/https://www.redmine.org/favicon.ico?16793021292010-09-12T04:36:20ZRedmineRedmine - Feature #6366: Due date on an issue should follow the associated release due date if it existshttps://www.redmine.org/issues/6366?journal_id=202032010-09-12T04:36:20ZBurt Culver
<ul></ul><p>try <a class="external" href="http://www.redmine.org/wiki/1/PluginIssueDueDate">http://www.redmine.org/wiki/1/PluginIssueDueDate</a></p> Redmine - Feature #6366: Due date on an issue should follow the associated release due date if it existshttps://www.redmine.org/issues/6366?journal_id=202192010-09-13T02:08:07ZTony Jacobs
<ul></ul><p>This plugin looks like it will work for what I'm trying to do right now, but it's not the 'right way' to solve the problem. The 'right way', I believe would be to leave the due date field on the issue itself as undefined. The subtle distinction becomes apparent when moving an issue from version XX (due yyyymmdd) to version FUTURE (not due ever)</p> Redmine - Feature #6366: Due date on an issue should follow the associated release due date if it existshttps://www.redmine.org/issues/6366?journal_id=202592010-09-13T20:58:28ZTerence Mill
<ul></ul><p>I share Tony's opinion.</p>
<p>The question shall be:</p>
<p>Does a ticket with a "due date > assigned projects due date" every would make sense?<br />If a ticket has no due date, and gets set automatically the projects due date, one can never find such tickets which has ever explicit scheduled.</p> Redmine - Feature #6366: Due date on an issue should follow the associated release due date if it existshttps://www.redmine.org/issues/6366?journal_id=202642010-09-14T02:20:10ZTony Jacobs
<ul></ul><p><a class="user active" href="https://www.redmine.org/users/43760">Terence Hersbach</a>:<br />Consider this case:</p>
<p>Feature <em>foo</em> is required for a major deliverable on August 1.</p>
<p>Release alpha is due on May 1, and <em>foo</em> is included in that release's requirements because it makes sense/risk reduction/whatever. It is a candidate to slip to Release beta on June 1, or to Release gamma on July 1.</p>
<p>Here, we can easily see that since <em>foo</em>'s due date is well beyond release alpha, we can slip it to a follow-on release.</p> Redmine - Feature #6366: Due date on an issue should follow the associated release due date if it existshttps://www.redmine.org/issues/6366?journal_id=202722010-09-14T09:33:08ZTerence Mill
<ul></ul><p>Well, i think you mixing two kind of versioning. Product (marketing) release versions (where features are officially available for customer) and software release, what means the feature is implemented in code.<br />Another thing you have to imagine is, that every software version cycles from requirements>planning>implementing>testing (acceptance, integration)> production. In Enterprise busines you mostly have no alpha or beta released to production, so the release on may1 or any before August1, will go into tesing environments</p>
<p>version May 0.8 (alpha)<br />due date: May 1<br />release environment: customer acceptance test<br />- Feature "foo" implemented</p>
<p>version 0.9 (beta)<br />due date: June 1<br />release environment: Customer system integration test<br />- BUF FIX for "foo" resolved (tickets from acceptance test)</p>
<p>version 1.0 RC<br />due date: August 1<br />release environment: Customer production<br />- BUF FIX for "foo" resolved (tickets from integration test)</p>