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

Next challenges

Recent achievements

Recognition

  • Give kudos
  • My kudos

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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?

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
Community showcase
Published in Bamboo

Bamboo 7.1 is here and is packed with value!

I'm happy to announce that Bamboo 7.1 has been released and it’s overflowing with awesome new features. Top-voted issues First and foremost, a bunch of JAC top voted issues has been delivered - y...

696 views 1 6
Read article

Community Events

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

Events near you