Versions apply to several projects

[Ianaré Sévi]

Hi, we would like to split up a very large project into smaller sub-projects. This is to divide by teams responsible and also to define components of each project.

Only problem is with project versions, in some cases we need to have a version applicable to all projects in a cetagory, other times only one or two of the projects will be impacted.

Is such a settup possible ? If not what organizational layout would you suggest ?

Thanks

[Glenn Bieger]

Another options would be to create a separate JIRA project dedicated to releases. Within this project each ticket/issue represents a release. You can then link the tickets from multiple projects to a "Release" ticket. Doing it this way, using JIRA out-of the-box functionality, will also allow you to:

• set up a specific release workflow, including CAB approval and potentially even deployment steps
• you can add custom fields to it to capture additional information per release
• you can use JIRA's powerful search engine to search through releases
• you can create a custom field 'Release Date' and use that to map/view all releases on a calendar widget

[Bob Swift OSS (Bob Swift Atlassian Apps)]

Versions are project specific, so you would need to create a version for each project where it is applicable. A version could have the same name in each project. copyVersion and copyVersions action have been added to the JIRA Command Line Interface. There is now a replace option to make it easier to keep versions in sync between projects. A 2.2.0 snapshot is available with this support - https://bitbucket.org/bob_swift/jira-cli/downloads?highlight=33403

[Ianaré Sévi]

Yes this is what I saw in the default config.

Problem is if the version release date changes, for example, then all the other projects would need to be updated as well. This would be a real time-killer, and an inneficient use of personnel.

I was hoping there was some config option or a plugin that would address this seemingly common need.

[Remie Bolte]

@dean / @ianara: I don't know if this is still an issue for you, but we have just launched our Version Sync add-on for JIRA to the Marketplace that will do exactly this. It will automatically keep versions in sync between multiple projects, where you have one "Master" project and an unlimited number of linked projects to which version changes are propagated.

[Nic Brough -Adaptavist-]

Can't be done at the moment. The previous answers cover everything I wanted to say, except that you might want to read and vote on the issue that is logged for this with Atlassian

[Adam Saint-Prix]

I really wish version and component schemes were possible, at least at the project level. I keep bumping into this problem where 20 teams are on the same release schedule and end users have to manually update the version and component information.

I guess you can now do this through the API though, couldn't you? Hmmm..might have to look into that.

[dinesh prabhu]

Is that possible to create the multiple versions of the same project by changing the release date? 

[Nic Brough -Adaptavist-]

I'm not sure what you mean by that, it does not make any sense in Jira speak.

  A version is a tag you apply to a set of issues.  It comes with a release date to tell people when that set of issues were fixed and released.

[Dean Vermeire]

Thanks for the replies! I'll go vote.

[Martin Cooper]

Versions and components only exist at the project level and are not shared across projects.

There is nothing stopping you using the same version naming convention across projects, but within each project reports and statistics will only reflect that projects versions, as it is independant.

You can use filters to search on a fixVersion and affectedVersion to to get information cross projects and use this filter as the basis for dashboard gadgets.

It does depend on what your requirement for this is, If you need to report at a high level then the filters may be good enough, but if you need to see cross project metrics at a lower level within the each project this may not be sufficient.

If use Greenhopper, then taking a look at the new labs feature, Rapid Boards, may help as that can provide a cross project view.

But in a lot of working scenarios, the fact that the version is called the same is enough to tie it together.