Better use of Change Log - Fixed In Version

General discussion of Mantis.

Moderators: Developer, Contributor

Post Reply
Posts: 219
Joined: 14 Feb 2006, 02:53
Location: USA

Better use of Change Log - Fixed In Version

Post by Starbuck »

I'd like to understand how others use Change Logs between "published" updates.

Example: v1 and v2 are major releases.
v1.1 and v1.2 are minor updates
v1.1.1 and v1.1.2 are patches which are released as required but they will appear in 1.2 when it is released.

Someone enters at ticket against v1.1. It is Fixed In Version 1.1.1.
Another ticket is created against v1.1. It is Fixed In Version 1.1.2.

The current Change Log shows these issues for 1.1.1 and 1.1.2. We build up a number of these and now we want to release version 1.2.

The v1.2 Change Log is inadequate for direct publishing. It needs to be exported and assembled in a manner that's acceptable for public consumption:
- Export the change log for anything greater than v1.1.0, remove the break-down of the build/beta releases. This could be published for 1.2.
- But there might be a lot of "transient" issues in there, details that production users don't care about. So select whatever seems relevant to 1.2 production users, and just report those significant changes.

Another way to approach that is to create a new Custom Field which is the Release Version. It's not the exact Fixed In Build version. It's the version where the change is going to appear - or in hind-sight the version where it did appear. With a new custom field, we won't use the Change Log functionality. So let's take this a step further. Since we're not reporting the version where a change was actually made, we're defining a new version, let's also create a Release Description. Then we can use the standard View Issues Filter, export all issues for the Release Version, and report the changes in a way that is acceptable for public consumption.

Why a Release Description versus the actual Summary? Everyone reports a problem differently, with bad grammar or spelling, and sometimes the problem report isn't really the actual problem. For example, Summary="why dont field show on screen?" Do we really want that to show in a change log? Consider Release Description="Fixed issue where authorized fields were not shown on Foo tab of Bar page".

I think this is a common challenge for all Mantis admins. I have the same thought process for every Mantis site I install.

Am I not using Mantis properly?
Are people using better ways to approach this?
Should this approach, creating a new change log by exporting custom fields, be suggested to others wondering about change log limits?
Should I look for tickets and maybe try to provide code related to this concept?

If you want Mantis to work differently, use or create a plugin. Visit the Plugins forums.
Ask developers to create a plugin that you need - and motivate them to help you!
Post Reply