My companies current processes rely on versioning on what would be defined as a component within JIRA. Is there a method for tracking version information at this level? Managing each component as a separate project would not be feasible in our structure.
Component versioning is a long-standing open feature request:
The updated description that says ..."we won't be able to fit this issue into the JIRA roadmap for the next 12 months" was added on May 27th 2011 - so I guess that we are in with a chance for 2012. But I would not hold my breath.
Note that there is a suggested work-around: use cascading select custom field.
As Mark suggested a cascading select would work.
Another option is to use the behaviours plugin and take a look at the behaviour to 'Add or remove options to a single or multi-select fileds, (https://studio.plugins.atlassian.com/wiki/display/JBHV/Miscellaneous+Behaviours+Examples#MiscellaneousBehavioursExamples-Addorremoveoptionstosingleormultiselectfields) The example that is given there is with componenets and subcomponents, or in your case it would be components and component versions.
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 read 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. We welcome any feedbacks.
There's a free non-plugin solution available.
Components are strings and can be used to track any aspect of your project which you find useful.
Versions don't have to be numbers; they are also just strings.
So, just create Components corresponding to each of your microservices/apps/whatever, e.g. serviceA, serviceB...
Then create Versions using a <Component>-<version number> convention, e.g. serviceA-1.0, serviceA-1.1...
How is this not as good as the Component Versioning everyone asked for and will never get anyway?
The only problem I have come across with this approach is that you're forced to abbreviate your Component names to keep the Version strings short, so that they are fully visible in the Version labels you see in Issue lists. Not a huge deal given that Component Descriptions can be verbose.
Learn how to use two new reports for next-gen projects in Jira Cloud: Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events