Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Semantic versioning with Bamboo

First off I know that Bamboo doesn't officially support resetting build numbers.

I'm currently using the build number to manage our semantic versions.  So we declare that we're working on version 4.2 of our product and Bamboo gives us the build number that we slap on the end, e.g. 4.2.38.

The problem is, when we bump to 4.3, we should really start back at 4.3.1.  The way it is right now our first build of 4.3 may be something like 4.3.39.

What am I missing?  This seems to be a very basic thing which makes me wonder if there is a different mechanism I should be using besides assembling the version using Bamboo's build number variable.

1 answer

0 votes
Daniel Santos
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Aug 13, 2018

Hello @byoung_novetta,

I do recommend you to use the auto incremented release version feature as described in this page: Naming versions for deployment releases - Atlassian Documentation.

You will also be able to use variables to compose the version, but the last number should be defined in the deployment configuration so it can be automatically incremented and manually reset to 0 when you need to run a new sequence of releases.

Thanks- I took your recommendation and set up a deployment project that uses Maven's version and deploy goals that I was previously using in my build plan.  It works.

The issue here is that builds aren't known by an official version until released.

With my previous approach, every build got a distinct, incremented version and if my QA dept. says "version 1.4.123 is cleared for release" we all have a common vocabulary and artifact-1.4.123 gets promoted on to Artifactory.

With the updated approach, I suppose artifacts have to take on a name like artifact-1.4-SNAPSHOT until they are released and my QA dept. would have to somehow know that artifact-1.4-SNAPSHOT.jar = Bamboo build #78, which ultimately may result in artifact-1.4.123 if promoted.

It is easier if the artifact is named artifact-1.4.123 from the get-go, which represents Bamboo build #123, which will still be artifact-1.4.123 if we elect to promote it as a release.  

Am I thinking about this in the wrong way, perhaps?

Daniel Santos
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Aug 14, 2018

Hi Brian,

You should be able to find a reference between each release and the build used to create it through the Bamboo UI (Deploy >> All deployment projects >> (YOUR_DEPLOYMENT) >> Releases). Is that enough for your team to discover the right build?

If you want you can also carry the build number in your revision string as an extra reference. Each company has its own way of managing this type of thing. It depends on your process. 

You could be using the deployment project to deploy your artifacts to a QA environment and having a different environment for the final release. As I said it might change the way your team will treat the results. 

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events