From: Roland B. <ro...@at...> - 2014-10-29 19:52:27
|
> 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. > I would prefer this to happen in the core Such kind of hidden data change will confuse users. > Robert Munteanu <rob...@gm...> hat am 25. Oktober 2014 um 11:37 > geschrieben: > > > On Sat, Oct 25, 2014 at 12:35 PM, Roland Becker <ro...@at...> wrote: > >> 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 > > > > >> Robert Munteanu <rob...@gm...> hat am 25. Oktober 2014 um > >> 11:24 > >> geschrieben: > >> > >> > >> 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/ > >> > >> ------------------------------------------------------------------------------ > >> _______________________________________________ > >> mantisbt-dev mailing list > >> man...@li... > >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > > -- > http://robert.muntea.nu/ |