Blog

If you use Redmine versions intensively, eventually you will want to have a flexible global versions overview, where you’ll be able to: list upcoming versions of all your projects, evaluate their status and progress, check their due dates in order to plan the release schedule, and so on. Unfortunately, the pure Redmine comes only with a simple per-project version list, which cannot even be sorted or filtered, or customized in any other way. Obviously, this functionality is too limited for many advanced use cases.

I was contacted by Cristian Tarara from Westaco regarding this problem. In Westaco, they use project versions to organize their work plan, so this issue is quite critical for them. Cristian asked me to add global and per-project version lists, that can be filtered by fields just like this can be done for issues and time entries. He also suggested to add dynamically calculated virtual fields, such as Estimated duration. Cristian wanted this solution to be developed as an open source plugin, that everyone will be able to use. So, if you find this plugin useful, you know who to thank!

The Westaco Versions plugin (named after the company, that sponsored its development) adds a new version list, that supports the Query similar to Redmine’s native issue and spent time lists (by the Query I mean the functionality, that allows to filter entries, choose which fields to show, group results and calculate totals — that’s how this functionality is named internally). Like issue and spent time lists, the new version list is available at the global level, i.e., for all projects (Projects → Versions), and at the project level (the new project’s Versions menu item). Unlike the legacy list, i.e., Roadmap, versions in the new list are listed in a table, in which most columns are sortable.

As you can see on the picture, in the new list you can filter versions by: Status, Project, Name, Description, Sharing, Due date, Start date, End date, Closed (date), Created (date), Updated (date) and Project’s Default version (a flag, which indicates, that the version is the default version for its project). In the new version list at the project level you can also filter by Subproject.

In the Options section of the query form (which is contracted by default), you can configure, which columns to include into the list, whether to group versions by some fields and which total values to compute. Thus, in Columns you can select: Project, Name, Description, Status, Start date, End date, Due date, Closed (date), Sharing, Wiki page, Default (a flag indicating, if the version is default for its project), Created (date), Updated (date), % Done (a progress bar), (number of) Issues, (number of) Open issues, (number of) Closed issues, Estimated time (of version’s issues, in hours), Spent time (for version’s issues, in hours), Estimated duration, Actual duration, Remaining duration and Extra duration. The results, i.e., versions in the table, can be grouped by: Project, Sharing and Status. For the whole results set the plugin can compute the totals: (number of) Issues, (number of) Open issues, (number of) Closed issues, Estimated time (in hours) and Spent time (in hours). If results are grouped, total values are computed for each group as well.

Also, as you might have noticed, the plugin adds new fields to the Redmine version object. These fields are:

• Start date (manual) is to be set to the date, when the work on the version was started (or is planed to be started).
• End date (manual) can be set to the date, when the main work on the version was finished (or is planed to be finished). But, it can also be the date, when the whole work on the version was finished. This date differs from the Due date in that the latter usually indicates the date, when the version is planned to be released.
• Closed (date) is set automatically, when the version is closed. Unlike the Due date this date indicates the actual release date, so they can differ, if the release was late (or early).

These three fields resemble corresponding fields of issues. The rest of the fields are dynamic, what means, that their values are calculated on the fly (and never stored anywhere):

• Estimated duration is the number of days between the start date or the creation date, if the start date is missing, and the due date. In this way, the field shows, how many days it took (or will take) from the very beginning to the release of the version.
• Actual duration is the number of days between the start date and the end date. In other words, this field shows, how many days were taken (or are planned to be taken) for the (main?) work on the version.
• Remaining duration is the number of days until the end date or the due date, if the former is not specified. By the way, something like this is already shown by the pure Redmine — it shows the number of days until the due date on the version page (using the label “Due in X days”), if the due date is in future.
• Extra duration is the number of days between the end date and the due date. This number can be negative, what would mean, that the version was finished earlier, than expected. If the number is positive, this means, that the version is late.

It should be emphasized, that the newly added fields do not have strict meanings — you can use them in the way, that you want. Thus, the end date can be used as the actual end date (and the due date — as the planned end date) or as the date, when, e.g., the development phase is finished (and the due date — as the date, when testing is finished).

Also, remember, that you can still use custom fields for versions, and they will be automatically supported by the version list query form.