Project

General

Profile

Actions

Feature #6366

open

Due date on an issue should follow the associated release due date if it exists

Added by Tony Jacobs over 13 years ago. Updated over 13 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
2010-09-11
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

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


Related issues

Related to Redmine - Patch #251: Patch for Feature Request #9785 (Default issues due date == assigned target version date)New

Actions
Related to Redmine - Feature #7626: version due date and issue due date interactionsNew2011-02-15

Actions
Related to Redmine - Feature #5451: Make Start Date/Due Date settable to versions/milestonesNew

Actions
Actions #2

Updated by Tony Jacobs over 13 years ago

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)

Actions #3

Updated by Terence Mill over 13 years ago

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.

Actions #4

Updated by Tony Jacobs over 13 years ago

Terence Hersbach:
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.

Actions #5

Updated by Terence Mill over 13 years ago

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)

Actions

Also available in: Atom PDF