Version vs. Build

[cdaniluk]

Mantis doesn't really differentiate clearly between a "build" and a "version". This has always been an issue for us, because issues are reported on the version (i.e. "2.0") and fixed in the build (i.e. "2.0 Build 1024"). I think most sizable projects work similar to that, though their terminology might be different. We could report issues by the build they occur in, but our users generally do not know. Plus, we find it more convenient from a retrospective perspective to see how "buggy" a release line was. If the data is lost in builds, that is somewhat difficult to do. On the roadmap side, builds aren't really a relevant concept. Thus, the "Product Version" and "Target Version" are true "versions", but the "Fixed in Version" is really a build.

We've gotten by to date by using the version field to hold both builds and versions. Users report by the version and when we resolve it, we mark it as fixed in NEXT BUILD. Upon build, we rename that version to the correct build number. This makes the changelog handy - we can quickly see what is coming in the next build (its listed at the top under NEXT BUILD), or what was fixed in the build that just happened.

It is a bit awkward, though. Users get confused by the dual-use field. The roadmap feature is difficult to use effectively. Search is also complicated. Ideally, Mantis would recognize builds as a logical child of the version and structure the changelog and roadmap accordingly. But, I think a solution that did that might be difficult to work into Mantis in the near-term.

Are there good workarounds that people are using? I've seen numerous posts from others that have the same problem, but not much discussion.

- Cris

[vboctor]

I've seen a lot of people doing what you are doing and I was actually recommending the "Next Version" or "Next Build" trick as the way to go. However, some people do it on a less granular bases (e.g. in the Mantis Bug Tracker itself), where we don't track build but we track versions or other projects track milestones or deliverable releases.

I would be interested to hear more suggestions about how users would like Mantis changed in this area. Go with a hierarchy where every version has N builds? Should the build be free text or a predefined set, where the nightly build would automatically register itself in Mantis and hence become selectable by users when setting the fixed in build. Also if we care about specifying build numbers to users, this means that they should also report bugs against build numbers, rather than just versions.

[cdaniluk]

I agree that not a lot of people do it the way we do it. Some probably might if the tool were more amenable to it, but most probably don't care at the level of detail we do. So, any fix would have to be friendly to everyone.

For this project, we never report bugs against build. I think it would be nice to be able to specify a build optionally, but a lot of times the reporter just doesn't know. In this case, its a webapp, so even some of our internal people don't always know. We also never resolve a build against a nightly. This is part of our QA workflow... bugs can only be resolved against a formal integration build, which we tend to do twice-weekly during development. The issues resolved against an integration build must be closed by QA before the build can be moved out to test or production.

This is the one thing I love about the way we currently use Mantis - I haven't found another tool, even Jira, that can manage our release workflow. With Mantis, it is pretty simple. The only real problem is the clutter between versions and builds, particularly in the reports.

[dingfelder]

Personally, I think that the build number should be used when specifying a version a bug is found in.

We use a 4 digit version number (major.minor.patch.build) which I think is a pretty standard way of doing things.
We then use the first 3 digits in the mantis version number (major.minor.patch) and the 4th digit is specified by the "build" field.

The only thing I would like to change about the way mantis uses versions is that It is annoying that I can not specify what build a defect was fixed in.

[vboctor]

If I understand the feedback correctly, then the issue can be fixed by doing the following:

1. Adding a "Fixed in Build" field to the issue table.
2. Allowing developers to set the "Fixed in Version" and "Fixed in Build" when resolving the issue.
3. Maybe consider grouping the roadmap entries by the "fixed in build".

As for the reporting side, the users can already report the product version and product build, which are both optional fields.

[dingfelder]

I think that is right.

I'm not 100% sure if the roadmap report needs to consider the release build.
If the issue is not yet closed, it would have no build (obviously). once it was closed though, perhaps grouping by build might be good... I would have to see it in action to tell if it made the report too complicated.

What about the change log though?
Not sure if ordering by bug # is right or by build # then bug #.

[allan]

Nice topic...

To adress this issue, here I created a new status called "implemented", where the source code has been commited in the SCM (svn or git) but it wasn't released yet.
Most of the time when the developer is resolving an issue, he doesn't know what version will cover it and since I made "Fixed in version" a required field, he was unable to change the status to "resolved". So they were taking note of each "fixed but not released issue" on a notepad, to set the status to resolved later when all the issues from that module was resolved and the version number was known.
Because of this I created the status "implemented" as a intermediary situation between "assign" and "resolved".
I think this is more simple than to use builds in my case, since we release versions once a week to testers and once a month to the clients.
Better than use builds, I think the integration with the SCM can be more useful.

[Lenge]

Does anybody know if this topic is already targeted for some future Mantis version?
I would vote for a rather simple but effective solution:

1. Introduce a new "Fixed in build" field (like already suggested)
2. Introduce 4 new configuration options to make the "Product version", "Build", "Fixed in version" and the new "Fixed in Build" fields either mandatory or optional.

Jens

[regi24]

Does anybody know if this topic is already targeted for some future Mantis version?
I would vote for a rather simple but effective solution:

1. Introduce a new "Fixed in build" field (like already suggested)
2. Introduce 4 new configuration options to make the "Product version", "Build", "Fixed in version" and the new "Fixed in Build" fields either mandatory or optional.

Jens

I actually have the fields "Fixed in Build" and "Build" but as custom fields. They are mandatory (the first when solving an issue and the second one when reporting an issue).

We are working with this solution and it's quite ok. If developers don't know the target build they write "> build xxx" where "build xxx" is the the build where the issue was found.


Sergi.

[Lenge]

Yet still, Mantis should have a built-in "Fixed in build" field.
And it really lacks configurable options to make built-in fields mandatory (just like you can with custom fields).

@Mantis team: How are the chances to get these two features in?