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

Discussion:

Robert Munteanu

2014-10-25 09:24:09 UTC

Hi,

I was thinking that having two different version fields ( target
version and fixed in version ) in a bug can be confusing for some
users. I understand that there are some advanced use cases, but IMO we
should also optimize for the simple workflow, where fix version should
be the same as the target version.

For that I suggest the following enhancement for 1.3:

When modifying a bug such that
- status >= bug_resolved_status_threshold
- resolution >= bug_resolution_fixed_threshold
- target_version exists
- fixed_in_version is empty

Then automatically set the fixed_in_version to be equal to the target_version.

Thoughts?

Robert

--
http://robert.muntea.nu/

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

Roland Becker

2014-10-25 09:35:45 UTC

Permalink

Post by Robert Munteanu
Then automatically set the fixed_in_version to be equal to the target_version.

Do you want this to take place in the UI or in the core (bug_api.php)?

Post by Robert Munteanu
Hi,
I was thinking that having two different version fields ( target
version and fixed in version ) in a bug can be confusing for some
users. I understand that there are some advanced use cases, but IMO we
should also optimize for the simple workflow, where fix version should
be the same as the target version.
When modifying a bug such that
- status >= bug_resolved_status_threshold
- resolution >= bug_resolution_fixed_threshold
- target_version exists
- fixed_in_version is empty
Then automatically set the fixed_in_version to be equal to the target_version.
Thoughts?
Robert
--
http://robert.muntea.nu/
------------------------------------------------------------------------------
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

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

Robert Munteanu

2014-10-25 09:37:26 UTC

Permalink

Post by Roland Becker

Post by Robert Munteanu
Then automatically set the fixed_in_version to be equal to the target_version.

Do you want this to take place in the UI or in the core (bug_api.php)?

I would prefer this to happen in the core so that it's available to
the SOAP API as well.

I realise that we possibly have one edge case here - users who desire
to have target_version set but fix_in_version empty. However, I hope
that's not really happening in practice.

Robert

Post by Roland Becker

--
http://robert.muntea.nu/

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

P Richards

2014-10-25 09:41:21 UTC

Permalink

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

-----Original Message-----
From: Robert Munteanu [mailto:***@gmail.com]
Sent: 25 October 2014 10:37
To: Roland Becker
Cc: developer discussions
Subject: Re: [mantisbt-dev] Simplify Target Version/Fixed in Version
management for 1.3

Post by Roland Becker

Post by Robert Munteanu
Then automatically set the fixed_in_version to be equal to the target_version.

Do you want this to take place in the UI or in the core (bug_api.php)?

I would prefer this to happen in the core so that it's available to the SOAP
API as well.

I realise that we possibly have one edge case here - users who desire to
have target_version set but fix_in_version empty. However, I hope that's not
really happening in practice.

Robert

Post by Roland Becker

Post by Robert Munteanu
Hi,
I was thinking that having two different version fields ( target
version and fixed in version ) in a bug can be confusing for some
users. I understand that there are some advanced use cases, but IMO
we should also optimize for the simple workflow, where fix version
should be the same as the target version.
When modifying a bug such that
- status >= bug_resolved_status_threshold
- resolution >= bug_resolution_fixed_threshold
- target_version exists
- fixed_in_version is empty
Then automatically set the fixed_in_version to be equal to the target_version.
Thoughts?
Robert
--
http://robert.muntea.nu/
---------------------------------------------------------------------
--------- _______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

--
http://robert.muntea.nu/

----------------------------------------------------------------------------
--
_______________________________________________
mantisbt-dev mailing list
mantisbt-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

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

Robert Munteanu

2014-10-25 09:52:01 UTC

Permalink

Post by P Richards
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/

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

Alain D'EURVEILHER

2014-10-25 22:42:43 UTC

Permalink

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

Post by Robert Munteanu

Hm, here's how I tend to do things, not sure if it applies to everyone
- 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
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

Roland Becker

2014-10-29 19:52:15 UTC

Permalink

Post by Robert Munteanu
I realise that we possibly have one edge case here - users who desire
to have target_version set but fix_in_version empty. However, I hope
that's not really happening in practice.

This is exactly what's the plan for 1.3.x after the first release is out:
Set fixed_in_version empty where version is 1.3.0dev to exclude the regressions
from changelog.

Post by Robert Munteanu
I would prefer this to happen in the core

Such kind of hidden data change will confuse users.

Post by Robert Munteanu

Post by Roland Becker

Post by Robert Munteanu
Then automatically set the fixed_in_version to be equal to the target_version.

Do you want this to take place in the UI or in the core (bug_api.php)?

I would prefer this to happen in the core so that it's available to
the SOAP API as well.
I realise that we possibly have one edge case here - users who desire
to have target_version set but fix_in_version empty. However, I hope
that's not really happening in practice.
Robert

Post by Roland Becker

--
http://robert.muntea.nu/

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