Fixed in Version understanding

Get help from other users here.

Moderators: Developer, Contributor

Post Reply

Fixed in Version understanding

Post by Ruben »


i have one problem to use the "Fixed in Version", when a devleoper solves a problem he needs to enter the version number. But he can select only "version numbers" which are previous added by the "manager".

But is not the "developer" the person who decide to open and add a new version...
Posts: 509
Joined: 14 Feb 2005, 03:38
Location: Ottawa, Canada

Post by thraxisp »

In larger organizations, it is more likely that the project team or management that determines the release arrangement. If this is a very small organization, you could give the team leader "MANAGER" access to allow them to change the specific project.
Glenn Henshaw Logical Outcome Ltd.
Mantis developer and user w:
Posts: 39
Joined: 10 Apr 2006, 20:56

Post by mroeder »

Since the exact version or build number isn't known until the build is done, I'd suggest two things.

First, add "next-version" as one of the build numbers. When an engineer checks in the code for the fix, he sets the bug to "fixed in next-version".

Second, Mantis needs a way for the QA Manager to flip all the bugs that are asserted fixed. That is, every bug that's asserted fixed in "next-version" gets its Fixed In Version field updated to the latest version.

(Here's a user scenario: I get release notes from the dev lead which include a list of fixed bugs. I Vuew Issues and check off those bugs, then select "Mark as Fixed" in the popup menu. The next window asks me the new build version and perhaps a note. When I click that button, the new build version is added to the version list, and all the bugs are flipped to this new version.)

Third, there needs to be a search button so the QAEs can find fixed bugs they entered ... without entering a fiddly search set every time.
Posts: 108
Joined: 18 Aug 2005, 00:46
Location: santa cruz, ca

Post by atomoid »

For this very reason we created a custom field called "Fixed in Build" which is just a string field that can be filled out as needed. So we separate our major/minor version numbers. I set the "Fixed in Build" to be visible when a developer 'Resolves' a bug (i initially wanted to 'require' it but that causes problems where its required but is at the same time not visible in some configs, youll find a bug or two on this forum about that).

That way our engineers can mark a bug as fixed in a certain build (ie., build 123) and then select the "Fixed in Version" field as well (ie., 1.0.2). So this bug would be version

It makes it easier since noone has to wait for the manager to update the fields every build and its also much easier to search for all bugs fixed in, for instnace, version 1.0.2 which might cover many different builds (instead of having to create some monstrous advanced filter to include all of them).

I'm not sure why Mantis left this out, since they include "Project version" and "Project Build" fields, which follow the same thinking. Is it just an oversight? ? I'd just like to be able to move that field up to where the "Fixed in Version fields is in te bug view page (instead of down at the bottom) but thats for another thread somewhere...
Posts: 338
Joined: 17 Feb 2005, 09:45

Post by Narcissus »


When I get a chance to merge all my code I can send you a patch for that. Basically the code that we use replaces the 'fixed in version' field with 'fixed in build'. It's handled as a custom field, but displayed in place of the fixed in version.

We also made 'fixed in build' get populated by a function call that amalgamates all of the 'found in build' values (plus a few other niceties).

Post Reply