Re: [mantisbt-dev] Simplify Target Version/Fixed in Version management for 1.3

[Alain D'E. <ala...@gm...>]

Hi,I would like to +1 to the simplification of the workflow.

What I personnaly do is:

- create one or several sandbox version(s), such as "Not Planned", or "3.2.x", "3.x", "4.x", where "x" is really the letter x.

- then when we decide the roadmaps of the bug fix versions, for instance 3.2.1, 3.2.2, etc. target the bugs 3.2.1, 3.2.2, etc. instead of 3.2.x

- idem for the other major versions 3.x, 4.x (requirement versions).

And it is often annoying to have to set the fix in version all the time, as for us it is (almost) always the same than the target version.




The only exception is when we reject a bug, the fixed in version is blank (most of the cases we don't want these bugs listed in the changelog)




Regards,

AlainD.


—
Alain D'EURVEILHER

On Sat, Oct 25, 2014 at 11:52 AM, Robert Munteanu
<rob...@gm...> wrote:

> On Sat, Oct 25, 2014 at 12:41 PM, P Richards <pa...@ma...> wrote:
>> Wouldn't you want to do this the other way around?
>>
>> On mantisbt.org for instance, it tends to target 1.3.x
>>
>> Then when an issue is resolved, have user target the actual (future) version
>> it's fixed in i.e. 1.3.0, and at that point update the Target version to the
>> value set for fixed in version.
>>
>> Or even, update the target version to null at the point fixed in version is
>> set.
>>
>> The 2nd case might make more sense - as the target version for bug would
>> technically cease to exist once a bug had been fixed in a version.
>>
>> Paul
> Hm, here's how I tend to do things, not sure if it applies to everyone
> but I've seen this done in practice:
> - target some bugs for the X release so they show up on the roadmap page
> - resolve bugs, set fixed_in_version to the X release so they show up
> on the changelog page
> - when version X is released, mass change all bugs to target the X+1 release
> This is also what I see when working with other trackers ( except
> other trackers don't have two fields ) - issues are targeted to
> versions and moved when the version is released.
> The changes I proposed support this workflow - but we need to make
> sure that we don't invalidate use cases such as the one you outlined
> above.
> Robert
> -- 
> http://robert.muntea.nu/
> ------------------------------------------------------------------------------
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev