You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I know that I may update to latest version released whilst subscription is active.
but I don't know what constitutes a version.
My preferred interpretation is that (for Bitbucket) 7.6 LTS is the version, which was the last LTS version released during active subscription (specifically 7.6.7).
but that 7.6.10 which was released after active subscription is a hotfix on the version 7.6, and thus I am entitled to update to it.
This is very important because 7.6.10 contains support for GIT-LFS 3.0, and without it means that LFS is broken as clients continue to update to versions that break compatibility with our current bitbucket server.
Hi @Andrew Barnes ,
any new binary release is considered a version for Atlassian. It means that for example, if your subscription is active until July 1st and you want to upgrade Bitbucket on August 1st:
In your case, it means you won't be able to install version 7.6.10 unfortunately.
Let me know if this helps,
Thanks for your time replying.
I am sure however that I read that LTS version is exactly 7.x. and that I'm not to upgrade beyond 7.6. However what is different about LTS versions is that critical/security changes are supported and released as 7.6.x and that these are available for as long as the LTS remains in support (long term support).
May I ask you where you are getting your information from?
It's not new features, and the advancements beyond 7.6 that I'm after (certainly not for free). This change in git's api degrades the software as it was. it's now a lot less functional than it should be at this point. That's not Atlassian's choice to make this change, but a more unique scenario that also supports why I would expect the LTS versions to continue to be eligible for as long as that branch and feature set remains supported.
I'd appreciate some further clarification here, and links to source of this information. if you have it.
Furthermore, Confluence admins would have received instructions from atlassian to resolve critical CVE-2022-26134 which was emailed out on the 3/6/22.
"Atlassian recommends that you upgrade to the latest Long Term Support release"
there is no comment or reflection on subscription status. So again, i strongly feel that we are eligible to update within the LTS branch that was last available during active subscription.
can you tell me that I'm wrong?
The terms of server licensing only permit you to upgrade to versions released during the term of your support maintenance. If your server license expires, and then any new version is released, you won't be able to upgrade to it, even if it happens to be within the same minor version release numbering. (say from 7.13.0 to 7.13.7)
If you look at versioning as [Major].[Minor].[Point], even a new point release is a new version. The terms of the licensing is based on the date in which that version is publicly released by Atlassian, and not based upon whether or not you are currently on the same major nor same minor release. You can typically identify these release dates by looking through the release notes such as https://confluence.atlassian.com/doc/confluence-release-notes-327.html
@Andy Heinzer thanks for your message,
it's unfortunate that you chose the confluence release notes for your point because if instead you look at the bitbucket release notes here: Release notes | Bitbucket Data Center and Server 8.1 | Atlassian Documentation the "releases" align with my perception.
it's not an uncommon expectation that solutions such as bitbucket would want to maintain the security of their applications for their own reputation as well as out of respect for the online community in safe guarding past and present customers. It's new features that would drive sales and continued contracts not critical security issues that no-one wanted to buy. The software as you know is E.o.L and we are running cloud in parallel as we migrate multiple servers over.
In the mean time, we do need within reason to retain the functionality and security status, I don't expect to pay twice to maintain the status quo (and during this period of imposed migration).
If you click into the details of any of those minor versions, such as the Bitbucket Server 7.6 release notes, you can see that each point release has a documented release date for it.
If you are making a migration, then I strongly suggest that you create a support ticket for that migration over in https://support.atlassian.com/contact
It appears that our team generated an evaluation license on your behalf recently. This is one way to grant you at least 30 days in which you can use that time to upgrade the product.
Yes I think I have a one off solution that will work for me but only for this one off scenario. I was hoping to reach a more generic conclusion for the benefit of the community.
We all have differing terminology, but I see 7.6 is the feature branch, and the point releases are hotfixes. if you look at them, they really only contain work that had to be ported back to this feature branch because it solved problems that shouldn't have been in 7.6 in the first place, at least not in an ideal world anyway.
I do think something is a miss here, I really did expect someone to have made it clear that point/hotfix releases within the feature branch were eligible updates to retain features/security that past/present customers paid for.