Project, Component, or Version for different product OS platforms?

[Matt]

We have a few products that run on several (up to 7) different operating systems. I'm struggling a bit with how to best split those varieties of the product out within JIRA. We do plan on integrating with SVN and implementing automating builds, testing, etc.

Versions - do I just append the version number (ie. 9.5) with the OS? 9.5.iOS Are there any drawbacks to having lots of different versions within the same project?

Components - they don't seem set up for OS's, and no versioning within components.

Projects - seems to give the most flexibility with breaking out work, reporting, etc., but a bit cumbersome with the number of separate projects (total products x total OSs = ahhh!)

Any advice from those who have been through this before? Thanks!

[Harry Chan · Accepted solution]

Hi, the best way would be to put this as components or a separate custom field called operating system.

Version is for versioning of the products - used for road maps, what version has bugs and what version has the fix. It shouldn't be used for OS.

[Matt]

The component area seemed logical to me (even though that use seemed a little non-standard), my concern came when I read a bunch of users commenting on the inability to have versioning at a component level.

I'm not sure if that's sufficient reason to not use it though, seems the best fit.

Thanks for the reply

[Deniz Oğuz - The Starware]

We have developed a JIRA plugin that allows component specific version numbers. It enforces component specific versions on issue create, edit, inline edit and workflow screens. You can check it out at Atlassian Marketplace, Component and Bundle Versions for JIRA or at the plug-in's help page for more detailed manual. This Plugin also allows you to group different versions of different components into one bundle. At issue creation page, if you do not select any component, this plugin only allows you to select bundle version numbers. It also provides two new JQL functions (affectsBundle and fixedInBundle) to query issues affecting a bundle.

In your use case. You could just create one JIRA project for each of your product and define each OS version as a component. Define every possible version at project level. Once you have done with component and version definitions. You need to define which version is applible to which OS. Once you have done that plugin will ensure that only the versions applicable to selected OS will be displayed in issue version fields. We welcome any feedbacks.

[Matt]

We have decided to go with a project per product, and drop platforms (OS's) into components for now. Hopefully that set up will remain flexible enough down the road.

Thanks for the answers, all.

[Ryan Parker]

I'm interested to hear how this worked out for you. We are planning on following suit.

[Ramiro Pointis]

Hi Matt, as I see the best way will be having a project per OS, so you can difference in a better way. Then, inside the project you will have your development versions, as a SVN. For example, there can be a bug in a OS that won't affect others, so this OS particulary will need a new release version.

And the components will be parts of your development, like DB or UI or something like that.

Hope this helps.

[Colin Goudie]

Do you release versions for ALL OS's at the same time or totally independant?

If independant, you should probably work off versions using some custom Nomenclature.

If you just want to track issues against 1 or more OS's etc.. but they are released all together as a single version but multiple OS versions of that product version then go with a custom multi-select field.

[Matt]

Yes, release by OS is often independant (different timing).

We use a custom nomanclature that includes the OS in our builds/release names now. I had considered just porting that over to the JIRA version field, but it seemed like I was jamming too much data into one field that way.

Thanks for the reply