Sure, maybe it has been fixed in 6.1.0 but is not working in version 6.7.1.

calin.pirtea 6.1.0 is going to be released in few weeks, no exact date has been set though.

Yay.

About time... Are you releasing it today?

In Bamboo 6.1 we are adding an option to apply the version naming scheme to all the branches.

We are managing our version numbers by using the Inject Bamboo variables task. We have different naming logic depending on the branch. For example, we append -pre{build.number} if the build is from a feature branch. We assumed the release versioning variables we were using would work across all branches. It is surprising that the feature doesn't work as explained in their documentation: https://bamboo.corp.alkamitech.com/deploy/config/configureDeploymentProjectVersioning.action?id=28803078. This should be considered a bug, not an improvement. Please fix Atlassian.

Watching this thread for a good solution but in the mean time my hack is just to clone the deployment plan for every branch that we want to build/release.  It is horrible an time consuming and an absolute waste of resources to manage/do but that's what Atlassian is giving us.

What you'll have to do is take your "master" deployment and clone it.  On the clone, click the "edit the build plan" and change the branch to the custom plan branch you want. When the build fires, this branch deploy should fire and you will get a properly named/versioned release. 

Word of warning though, if you make a change to the master deploy project, you will need to manually apply that change to all of the cloned deploy projects.  We're trying to keep branch deploys to a minimum but we currently have 5 branches that get deployed and 1 master.

Bump. I know "bump" is bad, but given that this has been open since 2014, and we're now in 2017, perhaps renewing our interest in this issue by commenting on it will get the Bamboo team to pay attention to it...

We need to created releases from plan branches. The release name should be the release version generated by Gradle

For this I wanted to use an Inject Bamboo variables task getting the version from a properties file and saving it to a Bamboo variable. This does not work for plan branches

Can we get some feedback about this Atlassian? Also being discussed here: https://jira.atlassian.com/browse/BAM-14891

Any users with a workaround?

It's important for us to have all our release names tagged with the build numbers...

Forcing the naming convention for branches does not scale well at all. Now we have to rethink our procedures, archive structure and implement (more) workarounds to address small but significant restrictions in Bamboo.

Hello,

Just wanted to give you the quick status update regarding this issue. We are aware that this is important and sometimes even painful for you guys. So please accept my apologies for keeping it open for a long time, we know that it could be really frustrating.

I wanted to assure you that the Bamboo team right now is 100% focused on the delivering critically important features for Bamboo Server, so hopefully the upcoming releases will be really interesting and beneficial for your teams.

We are also going to revision and extend our roadmap plans soon, so I wanted to mention that we will consider this issue to be addressed. Please do not take this as any sort of promise, but looking at the activity and arguments you’ve mentioned here, this is a strong candidate for us to consider to deliver in future.

I will try to stay in touch with you and share the status how this issue is going. Feel free also to share any sort of your team’s requirements or other helpful data regarding this issue, so we can take it into consideration.

Cheers,
Stan, Product Manager for Bamboo.

If you follow this issue on the two boards it appears on, then check random issues more important than this one, you will see that most have less than 10 votes and hardly any watchers. Yet this issue is of lesser importance.

It's somewhat good to see others say this about bamboo because we were feeling a bit like the bad guys saying bamboo is rubbish. We are also looking to get away from bamboo for lots and lots of reasons, this issue included.

Last year they requested a feedback interview from us and we told them of our problems and our opinion of them. They made a lot of fuss about how they care about customer needs and so on and in the end they did nothing to fix any of the issues we highlighted as truly important to us.

Good luck with Jenkins.

I'm pushing daily to move away from bamboo. It is clear to me that you guys have zero priority on providing what we need in this product, and instead keep dreaming up new things for bamboo to do. And yet it already has issues doing what we need it to do now. This is a grand example of that, and every time we come looking for these critical features; they're completely stale and not being prioritized. As of today 10/18/16 I'm going to start spending my weekends to migrate us to Jenkins. If this works out for me I'll be telling everyone in the industry about it, and posting on reddit about it as well.

We are yet another company that needs this ASAP.

Atlassian, we really need this thing fixed!

Same problem here! please add this feature

another person who would like this feature

Atlassian, any updates on why this is taking so long to correct?

I guess is just Atlassian being Atlassian

Omg. This has been reported over 2.5 years ago and still hasn't been fixed. I can't imagine the fix being that hard. Why is it taking this long? Atlassian, please wake up!

This really should be fixed in the next release of Bamboo. Not allowing plan branches to inherit the release versioning from the main deployment project is stopping us from using plan branches as recommended by Atlassian. We either have to manually change the version naming for every deploy of a plan branch or just not use plan branches at all.

A missing feature isn't a bug, but this is certainly not low priority. As many have mentioned, this completely screws things up when you have multiple active branches and use merges to do CI/CD. We merge issues from branch to branch and ultimately deploy is automated. So changes are merged from trunk->QA->UAT->prod. Only one of these gets a sensible release naming convetion in Bamboo, and it is impossible to tell by looking at the name what is new and old. Obviously multiple issues are merged at once when going from stage to stage, so the Bamboo release version numbers don't even increment similarly.

Basically, +1 to this feature. You should also have "branch name" as a default variable.

This is a real big problem for our releases and deployments via bamboo. The version/release naming convention comes the builder (maven, leiningen, docker) project configuration files (pom.xml, project.clj, Dockerfile) in git and should not come from bamboo none master branch naming convention. This causes much confusion as our build artifacts stored in nexus repository manager and docker registry to not align with the release naming done by bamboo.

Bug. Of course it is a bug. And "Major", not "Minor" too.

The way I see this, it's not even an improvement but rather a bug? Why would someone state a complex naming scheme if it was only valid for the "default branch".
Please fix this ASAP. +1

I agree with remi561908144. This should be fixed ASAP. +1

Unbelievable that, more than 2 years after this issue creation, nothing has changed!
Even if you

want to revisit the release naming as part of a larger project to improve deployments and releases.

you could at least provide / implement a workaround.

Also running into this issue. Just trying to add our git hash to the release names so people know exactly what is where but it's only working on our main branch. Like other people have said, foobar-22 is not a useful release name to anyone.

+100 on having this fixed ASAP

I do not see this as a Minor improvement as this will cause us problems as we do not always release from trunk/Master branch.
It would be great to see this prioritised within the Deployments components backlog please?

Throwing our .02 in here also - please fix this

We also do not release from the master branch, and missing this feature means that we do need to freehand edit the release version. This is often a source of error.
For us it would be sufficient that the template defined for the master branch also took effect in the context of other/release branches.

The worst thing for our team is that this feature/bug stops us from automatic release naming cause we have no workaround for this. We have an app which is built for several countries and our CI on develop branch is used just to check if app can be built for all countries and tests are passing. We are releasing builds only on feature branches like feature/Country_FeatureName, so we always must enter a build version manually.
We strive that builds could be made by non dev people, but now they must know naming convention for each of the Country and Feature. That is a show stopper for us

Indeed. The generalized Atlassian perception/belief that the master branch is the only one that matters is a severely limiting feature in a number of integration points.

That's not promising news Sten. To push it off that far, you might as well tell us this feature is never going to happen. I feel this item request is not an "Improvement" as much as it's a "Bug". It inhibits CI workflow by restricting that releases can only come from the master branch.

A similar (and lingering) issue exists on the JIRA side when releasing a version to trigger a Bamboo plan, it doesn't allow you to select any branch build.

I know that's a different product...but same issue as far as we're concerned. It prevents us from CI automation which is why we don't bother using either functionality.

@spittet Did you mean 2016 there or did you mean 2015?

Hi liudvikas.aukstikalnis1,

Due to the current priorities on the roadmap it is unlikely that we will be able to deliver this improvement in 2016. However we intend to improve the Continuous Deployment story next year and, while I can't make any promise for this particular feature, you can expect us to deliver an improved experience around the deployments.

Regards,

Sten Pittet
Bamboo Product Manager

@spittet ,

Could you give an update for this?

Our company feels big pain because of lack of this feature. We need manual actions for Continuous Integration - that's not what everybody wants

Yep- that's exactly what we are experiencing. Hope it gets fixed soon. "master-7" is not super useful to me...

I'm not entirely clear about your comment. The essential issue is whatever string you specify in the "Release versioning" form, this will ONLY apply to the branch that is specified in the "Edit build plan" form. So if you set the "master" branch like we do, any other branch name you plan to release from (which most users do) will not following that string format.

Useless is the agreed upon theme here.

If I am understanding correctly- this issue relates to additional environment releases being named <branchname>-<version> despite whatever you specify in the "Release versioning" form? If so that is exactly what I am experiencing and all the other comments are correct. The release versioning is useless if it does not apply to all environments.

This ridiculous. August 2015 and this is still broken?!?

More frustration on this not being fixed https://jira.atlassian.com/browse/BAM-14886

Any updates for this for 2015?

Hi Sten,

Though that's not a resolution, I do appreciate the response and the status.

I believe we met at Summit 2014 and discussed a bit of "nice to haves" for Bamboo deployments. Any chance in the scope of your larger project, that Bamboo will the capability to manage the JIRA release versions? That would be huge win, and truly tie together your Build (Stash/Bamboo), Release (JIRA/Bamboo) and Deployment (Bamboo) tools ecosystem!

Ron Chan

Hi,

Due to current priorities on the roadmap it is hard for us to prioritise this issue in the backlog. I don't think that we will be able to address this before the end of the year. It seems like a small change but we want to revisit the release naming as part of a larger project to improve deployments and releases.

Thanks,

Sten Pittet
Bamboo Product Manager

The lack of any response simply exacerbates my frustration...

This is impacting us as well, we have teams who use admittedly poor branching strategies, but that's no reason not to support branch release naming. Right now it seems we can do manual release naming (bad!) or have them rename their branches to only be the expected version number.

We use Bamboo for continuous release (with automatic creation of releases). We also use release branches. This issue is not 'minor' in priority to us - it forces us to use a release naming scheme that is in conflict with our naming policy.

We have a deployment environment called 'Release and Verify', which triggers the automatic creation of a release. Our 'workaround' is to configure the deployment project to use a custom plan branch (our current release branch), which then allows us to configure the naming of our releases as we want them (for example, '3.10 build 7'). We have an additional trigger for the 'default' branch, which (because of this issue) ends up being named 'default-123' or similar.

This issue forces us to make a choice:

• Live with Bamboo's defaults and name our releases as '[branchname]-[buildnumber]' across the board
• Live with inconsistency and an annoying workaround, but have control over the names of our releases on the 'active' release branch

It is perhaps worth noting here that we have already made compromises to the way that we want the release identification to work because we don't have a global build number - they start at 1 when a branch is created. I'd rather just have a globally unique reference (within the plan, and regardless of the branch that the build is created on) to the build that generated the release. I can't see an existing improvement request for this feature (I'll raise one).

Is this on your work queue, is it a feature you're considering or is there some workaround that makes sense.

Can I please get a response for this?