How can I automate creating a new version after a version is released?

[Maroline Johnson]

Hi all, 

I'm trying to create an automation that will create a new version after a version is released. The catch I'm struggling with is defining the name of the version. 

Say I have a version named 1.0-ER-23.01. I release this, and I want my next version to be named 1.0-ER-23.02. 

How can I automate this naming convention where only the last character is changed? I'd like for it to add 1 to the previous version's character in that last position, sort of like an array. 

Thank you!

[Bill Sheboy · Accepted solution]

Hi @Maroline Johnson 

You can do that using an automation rule, triggered on version released, and create the new one by parsing the released version's name with text and math functions:

• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/
• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-math-expressions/

Do you want to always increment version 23, such as 23.01, 23.02...23.09, 23.10, or something else?  The better you define your scenario the easier it will be to test the rule.  I recommend breaking this up into pieces and writing to the audit log until you get it working.

Perhaps something like this:

{{version.name.substringBeforeLast(".")}}.{{version.name.substringAfterLast(".").asNumber.plus(1).leftpad(2,"0")}}

Kind regards,
Bill

[Stefan Salzl]

Amazing @Bill Sheboy 🙌🏼

Even if I‘m not the one who asked the question: 
Thanks for your great answers and letting me/us learn so much from you 🙏🏼

Best
Stefan

[Bill Sheboy]

Thanks, Stefan.

[Maroline Johnson]

Hi @Bill Sheboy 

Thank you so much for your input!

I want to increment version 23 up to 23.12 and then begin incrementing 24 from 24.01 up to .12. If we ever got to 29.12 then the next release should be named 30.01.

I've tried the smart values you suggested and ended up with something close... I put in {{version.name.substringBeforeLast(".")}}.{{version.name.substringAfterLast(".").asNumber.plus(1).leftpad(2,"0")}}, released a version called "9.1-ER-21.11" and got "9.1-ER-21." in the audit log. 

Do you have any further suggestions?

Thanks again!

[Bill Sheboy]

Thanks for clarifying as this scenario is a bit more complicated as both the major and minor versions increment.  The key is to check the minor version first and then increment as needed.

Below is a full rule, which I quickly tested and so I'd recommend trying this in a test project first.  After you are happy with it you can copy it to the final project.

• trigger: version released and matches your version filter.  For example:
  • Version name filter: 9.1-ER-*
• action: add to audit log the version released is {{version.name}}
• action: create variable
  • name: varVersionPrefix
  • value: {{version.name.substringBeforeLast("-")}}-
• action: create variable
  • name: varMajorVersion
  • value: {{version.name.substringAfterLast("-").substringBefore(".")}}
• action: create variable
  • name: varMinorVersion
  • value: {{version.name.substringAfterLast("-").substringAfter(".")}}
• if/else condition
  • advanced compare condition
    • first value: {{#=}}{{varMinorVersion.asNumber}}+1{{/}}
    • condition: greater than
    • second value 12
  • action: create variable
    • name: varMajorVersion
    • value: {{version.name.substringAfterLast("-").substringBefore(".").asNumber.plus(1).format("00")}}
  • action: create variable
    • name: varMinorVersion
    • value: 01
• else
  • action: create variable
    • name: varMinorVersion
    • value: {{version.name.substringAfterLast("-").substringAfter(".").asNumber.plus(1).format("00")}}
• action: create version
  • {{varVersionPrefix}}{{varMajorVersion}}.{{varMinorVersion}}

How this works...

1. Split the version name into pieces, pulling off the prefix, major, and minor versions
2. Check if the next minor version is over 12, and if so reset it to 01 and increment the major version
3. Otherwise...just increment the minor version
4. Then put the pieces together to create the version

Unfortunately, there are some challenges using created variables as function parameters, otherwise this rule could be much simpler.

Please let me know how this works for you.

[Maroline Johnson]

Incredible! That worked!

Thank you very much!

[ibrahim_aly]

Dear @Bill Sheboy 

I want to have a similar thing but iam kinda struggling with it

I need to create a custm field for project ID with this naming convention PR-YY-NNNN

where YY is the year 

and NN is the a sequence number starts from 0001

so for first project this year it is PR-23-0001

second one will be PR -23-0002

and so on

and automatically next year first project will be PR-24-0001 and so on

[Bill Sheboy]

Hi @ibrahim_aly -- Welcome to the Atlassian Community!

You seem to be asking a different question as this one relates to versions (releases) and you apparently want an increment for creating projects and determining their id value.

I recommend creating a new question, and linking to this one for reference.  Otherwise only the people following this thread will see it, and thus be able to offer help.

Kind regards,
Bill

[Elior Odinak]

I'm tryin to use this post to figure out an automation rule for creating a new version once a version is released. When defining the Version name in the Version name filter, does it need to be numerical? or can you just use "fixversion"?

I'm trying to set a rule to increase the number from 7.76 to 7.77 etc. When the current release version is set to Release, i want a new version to be created.

So my automation currently is When Version Released then Create version. Is that not right? Does it need to be longer than that?

[Bill Sheboy]

Hi @Elior Odinak -- Welcome to the Atlassian Community!

The version name is text and so it can be alphanumeric.

In your case you want to increment your prior version's name, which seems to be a number value.  And so the rule would be just as you described:

• triggered on version released
• an action to create the new version, parsing the old name to increment the value.

I recommend pausing to define your version naming, how it increments, and any exceptions.  That will help to create and test the rule.

Your Jira version (Cloud, Server, or Data Center) also impact how to make such a rule, as the different automation versions have different features.  For example, Cloud and Data Center have the Create Variable action, if you want to define the value in pieces, such as Major Version and Minor Version.  All three are able to perform a version increment inline, without using a variable.

Kind regards,
Bill

[Elior Odinak]

Thanks Bill! I think that's where I'm struggling is with the version naming. I know that it needs to increment on the "minor" number only. At some point we'll run out of those and it would then need to increment the major number, but for now it's just the minor one. I.e 7.77.0 to 7.78.0 to 7.79.0 to 7.80.0. But after reading all the rules on syntax, I'm still not clear on how to get Jira to increment in this way. Is there a document or video or something that explains how to utilize the syntax to do this?

[Bill Sheboy]

Successfully using automation rules requires learning and experimentation.  If you read this question's posts, from beginning to end, you will find all of the pieces and techniques needed to increment a version name with an automation rule.

Here are the documentation references which describe the rule features used to solve version incrementing.

Text functions to split and extract the version parts:
https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/

Created variables to store the pieces of the version parts:
https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Create-variable

Math functions to increment values:
https://support.atlassian.com/cloud-automation/docs/jira-smart-values-math-expressions/

Rule conditions, to decide when the major, minor, or both version components change:
https://support.atlassian.com/cloud-automation/docs/jira-automation-conditions/

I recommend trying to create a simple rule to start, test it, and incrementally improve it to add your other cases needed for the version increment.

If you run into challenges, create a new question, with a link to this thread, and include images of your rule details with an explanation of what does not work as you expected.  That will ensure a large number of community members see it to offer help.

[Joshua Dickerson]

@Bill Sheboy - First off, thank you for your knowledge. Second, I need to borrow some of it.

I am trying to set up a couple automations:

1- Set up the Release of tickets that are "Done" that have a fix version associated.

2- Create a new fix version with the same naming convention as the previous version.

ex. (Month) (Year) Support -> June 2024 Support

Any help with this would be greatly appreciated.

[Bill Sheboy]

Hi @Joshua Dickerson 

First thing, as this is an older thread it is often better to create a new question and link back to the older ones.  That ensures the maximum number of people see it to offer suggestions.  Otherwise, only people following the older threads see it.

Back to your questions...

You do not describe what are the triggering events for those rules. 

For example on your second rule noted, do you want the new version created when the current one is released?  If so, please review this entire thread to find the pieces needed.  In particular, you may use the date / time incrementing and format() function to create the new version name: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/#Date-format---

For the first rule you describe...what does "Set up the Release of tickets that are 'Done'..." mean?  Is that...

• as each issue moves to Done, a fix version is released for that one issue.  Or...
• as each issue moves to Done, check if that was the last one assigned to the fix version, and then release it
• and so on...

If you already have a rule started, posting images of the complete rule and audit log details, and explaining what is not working as expected, will help provide context for suggestions.  Thanks!

Kind regards,
Bill

[Anastasiia Tsvetkova]

Hi, bright minds.

Could you please help me to figure out what I can't see in my rule? At some point, it stopped to check on this > 12 for a minor version rule. And can't understand why...

It might be something pretty obvious.

p.s It does work fine for creating versions from Release.08.01-12. But after 12 it stops creating any further....

So, I took Bill's example and modified like this -> 

• trigger: version released and matches your version filter. I didn't fill anything here in particular. 
  • Examples of what Version name looks like: Release/08.12
• action: add to audit log the version released is {{version.name}}
• action: create variable
  • name: varVersionPrefix
  • value: {{version.name.substringBefore("/")}}/
• action: create variable
  • name: varMajorVersion
  • value: {{version.name.substringAfter("/").substringBefore(".")}}
• action: create variable
  • name: varMinorVersion
  • value: {{version.name.substringAfter(".")}}
• if/else condition
  • advanced compare condition
    • first value: {{#=}}{{varMinorVersion.asNumber}}+1{{/}}
    • condition: greater than
    • second value 12
  • action: create variable
    • name: varMajorVersion
    • value: {{version.name.substringAfter("/").substringBefore(".").asNumber.plus(1).format("00")}}
  • action: create variable
    • name: varMinorVersion
    • value: 01
• else
  • action: create variable
    • name: varMinorVersion
    • value: {{version.name.substringAfter(".").asNumber.plus(1).format("00")}}
• action: create version
  • {{varVersionPrefix}}{{varMajorVersion}}.{{varMinorVersion}}

Appreciate any comment. Thank you