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

Semantic versioning with Bamboo

byoung_novetta
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
August 9, 2018

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.
August 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.

byoung_novetta
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
August 14, 2018

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.
August 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
TAGS
AUG Leaders

Atlassian Community Events