[Mantisbt-dev] Fixed in Build vs. Fixed in Version

[Lincoln M. <Lin...@qu...>]

Hi all,

I was wondering what the overall feel was for implementing Fixed in Build
functionality to be used alongside / instead of Fixed in Version.

Although I see Fixed in Version functionality to be useful it would be hard
for us move over to using it as within this organisation, at least, we only
release one or two versions a year. Instead, we work on the idea of a new
build each day with testers reporting issues in a build and developers
fixing them in a later build.

I would like to know how many other people out there are in the same boat as
we are and what would be the best course of action to implement this Fixed
in Build feature (anywhere from an absolutely perfect solution, down to an
answer of "suck it up and deal with it yourself").

Firstly I want to tell you how we are currently dealing with it, followed by
another suggestion of how we could (and most likely, should) do this.

At the moment we have basically "hijacked" the Fixed in Version field to
mean Fixed in Build. We have a flag in the configuration file that tells us
whether we want to use Fixed in Version or Fixed in Build functionality.
When we use Fixed in Build, we do a few things:

1) Replace all mention of Fixed in Version with Fixed in Build, and replace
the dropdown lists for Fixed in Version with the Fixed in Build dropdown
lists.

2) Replace the (now) Fixed in Build dropdown data with a combination of any
data in the Build and (now) Fixed in Build data.

3) Replace the freetext field for Build with a dropdown list, comprised of
the same data as the Fixed in Build dropdown (this helps to standardise what
everyone is entering as a build).

4) Add a configuration flag such that at a particular level of access, a
user can select '[Create New Build]' from the dropdowns then enter a new
build number to be incorporated in the dropdown list from then on (it
basically allows freetext entry for when reporting or fixing an issue in a
particular build for the first time).

5) Fix the changelog page to show Fixed in Build, as opposed to Fixed in
Version.



The problem with our current implementation is that it's really messy to
maintain. Really, really messy. Although, this would probably not be as much
of a problem if we continued to use Fixed in Version, too (which we have
basically removed with our configuration flag). Unfortunately, this would
entail not hijacking the Fixed in Version field in the database, which led
me on to...

The other thought I had was to set up Fixed in Build as a custom field. With
our populating functions this shouldn't be too hard and all I would need to
do then would be:

1) Change the change log page to look at a custom field instead of the Fixed
in Version value.

2) A change that would affect (enhance?) the current custom field
functionality: Add another value for the custom field that would set access
levels for allowing the user to not only select from a current list, but
allow the user to enter a new value if need be.

3) As we also use a dropdown with "[Create New]" functionality on the normal
(found in) Build field, we would also have to populate this dropdown with
values from the Fixed in Build custom field. Seeing as this is a tweak we
use ourselves, I don't know if anyone else would even want this particular
feature.



So I guess the question (after, please, do you even understand my really
badly worded email??) is: would anyone be interested in "Fixed in Build"
functionality and how would you go about implementing it (or how have you
gone about implementing it)?


Thanks for any comments,
Lincoln.