+1. This is very important. Many a times versions are full projects or sprints where start and end dates are useful.
--------------------------------------------------------------------------------
Agree with you Dipan. So I hope that redmine team will do that in newer versions of the product
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Still not available in version 3.0.

Please kindly include this feature soon.
--------------------------------------------------------------------------------
+1 The issue is that it is misleading. new users enter the start date of the version instead of the due date. At least, rename the label to be 'due date' instead of just 'date'
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Amr Noaman wrote:
> At least, rename the label to be 'due date' instead of just 'date'

I have submitted a patch: #22315
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
+1
With this feature, we can see implementation period of the version in gantt. It is really useful.
--------------------------------------------------------------------------------
Go MAEDA wrote:
> +1
> With this feature, we can see implementation period of the version in gantt. It is really useful.

Totally agree. For example, in our instance, because we do not use start date for issues, we've created from the beginning a custom field to store the Start Date of the version, but is not so useful because is not used by any other Redmine feature. Furthermore, is quite confusing to have the due date first and after that the start date (screenshot attached).

I would like to work on this, but I'm not sure how to implement it considering the current functionality. I have 3 scenarios in mind:

1. A global setting to choose how the start date of the version should be calculated:
* minimum start date from the issues (current implementation)
* independent from issues

2. Above setting but at version level
3. No setting and use the start date from the issues when the Start date field of the version is not filled (it can be quite confusing for users).

I think that I prefer the first option.
--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> I would like to work on this, but I'm not sure how to implement it considering the current functionality. I have 3 scenarios in mind:
>
> 1. A global setting to choose how the start date of the version should be calculated:
> * minimum start date from the issues (current implementation)
> * independent from issues
>
> 2. Above setting but at version level
> 3. No setting and use the start date from the issues when the Start date field of the version is not filled (it can be quite confusing for users).

I prefer the third option. Currently, Redmine uses the earliest start date of the issues as version's start date (@Version#start_date@). The behavior of the third option is compatible with the current behavior and I think it can avoid confusing existing users.

<pre><code class="ruby">
def start_date
@start_date ||= fixed_issues.minimum('start_date')
end
</code></pre>
--------------------------------------------------------------------------------
Thanks for your feedback, Go Maeda.

My concern with this option is the following scenario:
* add a version without start date
* add at least one issue with start date to the version
* now, the version has the start date of the issue (current behaviour which is correct)
* open the edit version page
* observe that the start date field is filled with the start date of the issue, even if in the database, the start date is nil
* save the form
* the value will be saved in the database and the version will no longer take into consideration the earliest start date of the issues

Attached is a WIP patch to test the above scenario.

If you have any idea how to prevent this without adding a setting, please let me know. I'm very interested to have this feature.
--------------------------------------------------------------------------------
Go Maeda, please assign me after you are able to test the scenario.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Go Maeda, you're still interested on this feature? If yes, please let me know what do you think about my above concerns. I would like to propose an implementation of this feature for version:"4.1.0" and right now I'm in favour of adding a setting.
--------------------------------------------------------------------------------
+1
--------------------------------------------------------------------------------
Sebastian Paluch wrote:
> +1

Sebastian, which option do you prefer from note-11?
--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> Sebastian, which option do you prefer from note-11?

I don't like 1. as this is another system wide setting, we have many groups working on projects, using different processes and having diffeent preferences. The issue parent-child related system settings are one of fire makers...
I don't like 2. as this is too much work to set this for every version. We have hundreds of them.
Any setting like that should be made at project level. This works best when combined with project "templates".

The 3. is a functional solution. Simplest one and settings can always be added on top of that in future versions. For us it is important to have something finally implemented.

BTW. How would all that align with "due date" behavior? The due data is now independent from issues. Should it be also changed in the way for consistency?
--------------------------------------------------------------------------------
+1 for the 2nd proposal

Sebastian Paluch wrote:
> I don't like 2. as this is too much work to set this for every version. We have hundreds of them.
> Any setting like that should be made at project level. This works best when combined with project "templates".

What's the point? You have to set your start and end dates for each version, anyway. I think the effort of checking a box to set explicit dates is rather negligible. Having the setting in the version form makes the functionality comprehensible to the user. I would also toggle between a text field and the actual date fields based on the state of the checkbox.

--------------------------------------------------------------------------------
Bernhard Rohloff wrote:
> +1 for the 2nd proposal
>
> Sebastian Paluch wrote:
> > I don't like 2. as this is too much work to set this for every version. We have hundreds of them.
> > Any setting like that should be made at project level. This works best when combined with project "templates".
>
> What's the point? You have to set your start and end dates for each version, anyway. I think the effort of checking a box to set explicit dates is rather negligible. Having the setting in the version form makes the functionality comprehensible to the user. I would also toggle between a text field and the actual date fields based on the state of the checkbox.

You have answered your question already. Setting first an option/checkbox and then date in every version is two times more operations... and you get no benefit out of it, same behavior gives you 3rd proposal.
--------------------------------------------------------------------------------
Sebastian Paluch wrote:
> ... Setting first an option/checkbox and then date in every version is two times more operations... and you get no benefit out of it, same behavior gives you 3rd proposal.

Are we talking about changing dates of existing versions or about creating new versions at a scale of hundreds a day? Because from my standpoint as a user, clicking a single checkbox for every new version I create is not really a thing. Choosing the setting for the whole project feels a bit inflexible to me. Perhaps we can think about a mix of both. Having a default setting for new versions chosen on the project level but leaving it up to the creator to change it in the version settings form.
--------------------------------------------------------------------------------
Is there any progress on this? It would be such improvement having this done, ether option 2 or 3 :)
--------------------------------------------------------------------------------
+1 for me too.

It will be very useful

The start date need to be independent from issues

Because we can have an old issue already open from days... month... years ;) worked... just 10%... and complete after many version.
--------------------------------------------------------------------------------
Here's a complete patch that implements this feature in the way that is outlined by Marius in note-11 as scenario 3. It provides a workaround for the undesired behavior described by Marius in note-13.
The patch includes up-to-date test coverage that is partly adopted from the original ChiliProject implementation and that is updated to fit current Redmine.

Any feedback is welcome...
--------------------------------------------------------------------------------
Sebastian Paluch wrote:
> BTW. How would all that align with "due date" behavior? The due data is now independent from issues. Should it be also changed in the way for consistency?

I've extracted this to issue #35760.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
I'm working on some improvements of my latest patch posted in note-25.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

relates,Closed,22315,Change English translation for field_effective_date: "Date" to "Due date"
relates,New,35760,Add a fallback-mechanism to Version#due_date similar to Version#start_date
relates,Closed,35454,Project lines on Gantt (nearly) all start on the same single date
duplicates,Closed,19367,please add 'start date' for version