# Feature OP-18420 - Add support for multi values for the default Version field

Project: OpenProject
Status: closed
URL: https://community.openproject.org/work_packages/OP-18420

## Planning

| Attribute | Value |
| --- | --- |
| Date |  |
| Priority | Medium |
| Target versions | Wish List |
| Sprint |  |
| Backlog bucket |  |
| Votes | 1 |
| List |  |
| Roadmap |  |
| Relevance |  |

## OPEN POINTS / FEEDBACK

_No work packages_

## Features and Chunks

_No work packages_

## Bugs and other work packages

_No work packages_

## Technical Details

| Attribute | Value |
| --- | --- |
| Module |  |
| Feature Flag |  |
| Requires doc change | No |
| Enterprise plan |  |

## Details

| Attribute | Value |
| --- | --- |
| Pull preview |  |
| Mockups |  |
| Found in mobile app version |  |
| Follow-up feedback e-mail |  |
| Accessibility | No |

## People

| Attribute | Value |
| --- | --- |
| Assignee |  |
| Accountable |  |
| Product manager |  |
| Developers |  |
| Designer |  |
| Ordered by |  |
| Signed off by |  |
| Interest by |  |

## Estimates and progress

| Attribute | Value |
| --- | --- |
| PD (min) |  |
| PD (max) |  |
| Work |  |
| Labor costs |  |

## Description

Need: Be able to set a "fix version" for several branches.

Current problem: It's already possible to create a custom multi-valued Version field but that has limitations.

My current analysis (also [posted as a comment](https://community.openproject.org/projects/openproject/work_packages/30423/activity#comment-767434) but making it a proper work package so that we can centralize all discussions about the default Version):

  - The name of the default field "Version" is ambiguous (is it a "fix version", is it an "affects version", is it some other kind of version). I couldn't find how to rename it yet.

  - I don't think there's always a primary version and keeping a "Version" field + introducing another custom field (named "Backport Versions" for example) is IMO misleading and not the best. First you'd need to be able to rename "Version" to something like "Main Target Version" or "Main Fix Version". Then it creates a hierarchy between the "main" version and the "backport" ones, which is artificial and not needed IMO. I'd prefer to see all versions as equals.

  - Having several fields also make it harder to search (for all issues fixed in the branch XXX, you'll need to search for "Version = XXX" AND "Backport Versions = XXX".

  - The Roadmap view would be broken since it only takes into account the default "Version" field. So you'd have a very partial view of the roadmaps for the backport branches (missing a lot of work packages targeting branches).

  - IMO the best is to make the "Version" field multi-value. If you're worried about backward-compatibility, one idea is to offer a configuration option for the Roadmap feature (and any other feature using the "Version" field, idk if that exists or not), so that the field used to represent the versions is customizable. It would be configured to use the "Version" field by default but the user could implement his/her own custom multivalued version field and configure the roadmap to use it. The roadmap feature would just need to be modified slightly to support a multi-valued Version field.

  - Are there other features of OP using the default Version (other than the Roadmap feature)?

<br>