Vote #68097
未完了Due date on an issue should follow the associated release due date if it exists
0%
説明
When an issue does not have an end date assigned, but it does have a version assigned, and the version does have a date assigned, then the end date of the associated bug should be implicitly assumed to be the release date.
I think it's a misfeature to want the upper bound of an existing end date to be clamped to the release date, so I'm explicitly not asking for that here. Just when the end date is undefined / null.
Observed in Redmine 1.0.1 against MySQL 5.0.91
journals
try http://www.redmine.org/wiki/1/PluginIssueDueDate
--------------------------------------------------------------------------------
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)
--------------------------------------------------------------------------------
I share Tony's opinion.
The question shall be:
Does a ticket with a "due date > assigned projects due date" every would make sense?
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.
--------------------------------------------------------------------------------
@Terence:
Consider this case:
Feature _foo_ is required for a major deliverable on August 1.
Release alpha is due on May 1, and _foo_ 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.
Here, we can easily see that since _foo_'s due date is well beyond release alpha, we can slip it to a follow-on release.
--------------------------------------------------------------------------------
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.
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
version May 0.8 (alpha)
due date: May 1
release environment: customer acceptance test
- Feature "foo" implemented
version 0.9 (beta)
due date: June 1
release environment: Customer system integration test
- BUF FIX for "foo" resolved (tickets from acceptance test)
version 1.0 RC
due date: August 1
release environment: Customer production
- BUF FIX for "foo" resolved (tickets from integration test)
--------------------------------------------------------------------------------
related_issues
relates,New,251,Patch for Feature Request #9785 (Default issues due date == assigned target version date)
relates,New,7626,version due date and issue due date interactions
relates,New,5451,Make Start Date/Due Date settable to versions/milestones
表示するデータがありません