0

We've been using Jira for a number of years now, and one of the challenges we've had is our build team had been generating daily build numbers for versions in the specific software product versions.

i.e.

t 5.0 rev 1.0001

When we have a customer facing build, we make a new version.

c 5.0 rev 1

when we release a final build, we renumber it to be:

v 5.0

When files are checked into a build, our build management automatically generates a version in the project, but we don't want to lose the build numbering when we merge versions. Equally, we'd like the fields to be as easily searchable as versions are currently. We aren't using Jira-Agile (aka Jira Software) at present, but that's an option. I just don't know if Sprint versions will give us the flexibility we will need.

Has anyone got any thoughts on this, and how we would best be able to capture that requirement?

Scott
  • 347
  • 5
  • 16

1 Answers1

1

If you have one release per sprint then it would be possible to have a sprint name that followed your version syntax (e.g. sprint name = "t 5.0 rev 1.0001").

This won't give you much flexibility though, say if you needed to do an emergency bug fix release mid-sprint. It also won't allow you to track the daily build version increments.

Other things worth considering:

You could use custom fields for release type, version number and build number. The main advantage of this approach is that you could potentially use the JIRA API to have the build system update issues with the latest build number. It would be possible to then have a concatenated field that contained the entire version that would be easily searchable.

Another thing worth considering is using labels. For example you could have labels for the different types (customer facing, release, etc.). This won't make searching particularly user friendly though.

Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28
  • I might try using nFeed to generate searchable version numbers and have the build system populate that instead - thanks for your comments, I think it's worth trying both approaches, as we could still be using Sprints for intermediate releases which are much more important for customer responses. Thanks Barnaby. – Scott Mar 11 '16 at 04:28