Eligibility of LTS (server) updates/hotfixes released outside of subscription

[Andrew Barnes]

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.

Further details: 

[BSERV-12989] Support Git LFS 3.0 clients - Create and track feature requests for Atlassian products.

[Alexis Robert]

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: 

• if version 7.6.3 has been release on March 1st : you can install it as it was released when your subscription was active
• if version 7.6.15 is release on July 15th, then you won't be able to install it as it was release after your subscription expired

In your case, it means you won't be able to install version 7.6.10 unfortunately. 

Let me know if this helps, 

--Alexis

[Andrew Barnes]

Hi Alexis,

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. 

Thanks,

[Andrew Barnes]

@Alexis Robert ping

[Andrew Barnes]

@Alexis Robert 
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?

[Andy Heinzer]

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

[Andrew Barnes]

@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).

[Andy Heinzer]

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. 

[Andrew Barnes]

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.