Is there an official version number for the current Jira Cloud?

[Guy]

After digging everywhere I can't find a decent answer.

Some say there is a version number and some say there not.

I also came across this:

"we document the latest versions of JIRA Cloud by number, however, we don't have a public place to display this information for customers since they are not relevant at all."

So, which one is it?

[Nic Brough -Adaptavist-]

Technically, there is a version number, and you can get it with a REST call for system information.

But it is of no use to you.  You have no control over what version you will be using, it changes frequently, and it tells you nothing about compatibility with other systems.

Why are you looking for a version number?

[Tom Lewis]

Hi Nic,  I'd like to respectfully request that Atlassian developers add the cloud version number of the Jira/Confluence, etc. to the "About Jira" pop-up.

Blanket statements like, "but it is of no use to you.", remove an important aspect of customer service. 

In many cases, it is important to document versions of support software to perform CM on products that have significant impacts.

This is a pretty useless pop-up from a CM standpoint.

[Nic Brough -Adaptavist-]

I'm not sure why it's "removing an important aspect of customer service" to explain why something is of no use.

I think it's better customer service to explain it, because it empowers the customer to understand what they're looking at better.

That takes us back to the question - why do you want to see the version?  Of what use is it?  It is not something you can configure or manage, so what does it tell you that you can use in CM?   

[Tom Lewis]

Best I can say is that if a customer asks for the information, provide them with what they asked for, not excuses as to why it isn't available.  Post it to the About area, like every other piece of enterprise software.  Just because it is not configured or managed by the end user, doesn't mean that it doesn't need to be provided and easily accessible from a standard location.  Traceability is important in product development and sustainment.  Just because  one doesn't develop the operating system of the server, doesn't mean customers don't need to know what it was at a point in time in order to communicate issues they are experiencing as compared to a previous or future version of the software.  Just because something is in the cloud doesn't mean its version doesn't need to be tracked.  Just because you don't code the iOS for your iPhone doesn't mean you won't need to share that with a support team.  I hope that helps.  If not, I recommend reading up on ITIL, ITSM, various software related compliance directives and the importance of version control for everyone from the developer to the end user.

[David Grierson]

Tom - I think you're under some mis-understanding about who has responded to you.

@Nic Brough -Adaptavist-works for Adaptavist not Atlassian. He has responded in a Community with details about why it isn't available but isn't responding on behalf of Atlassian.

[Tom Lewis]

Hi David,  Thank you for the clarification.  Though, what does that have to do with the topic of this thread?   The concern is, these posts are from two years ago and Atlassian still can't seem to publish a version number of its Jira/Confluence cloud applications in the about area of the software.  Our organization is considering this as a potential system of interest.  This is going to be of concern in decision making efforts.

[David Grierson]

Sure - I get that ... however your response to Nic seemed to be frustrated at him as to why Atlassian (whom he is not a member of) don't supply a version number. What you're doing posting here is the equivalent of asking a Ford owners club as to why a particular model of Ford doesn't do a particular thing.

Nic's response however holds - it's of no use to you as it's not something which you have any control over. Even from a CM perspective it is not something which you'd have control over. This week it might be version 12, tomorrow it might be 48, the day after that it might be 716.

You make the point "like every other piece of enterprise software." That might be the case, however, this is a Cloud platform and the whole point of a Cloud platform is that software updates are transparent to you as the user. And Atlassian isn't the only Cloud platform provider which doesn't report the software version of their Cloud platform; Github.com doesn't report this either.

If you want an accurate response as to why there's no point in getting angry with me or Nic about why Atlassian have chosen not to expose the version number to the end user, you should raise a support case with Atlassian to see why they're not doing it.

[Tom Lewis]

I am not sure why you think that emotion has anything to do with what I've said. 

I do know that written words are difficult to decipher as it takes into account the attitude of the receiver of the message and is equally difficult to try to fit concepts into fewer words.

My thought is that Atlassian would monitor their own community and take suggestions from it.  Thanks for letting me know that is not the case.

The point of any application, is to provide customers with what they view as important. No more, no less. 

[Nic Brough -Adaptavist-]

>The point of any application, is to provide customers with what they view as important.

No, it's to provide customers with things that are important.  Most of the time, what the customers think is important is actually important, so it's the same thing. 

But in this case of the version of Cloud, the customer is wrong.  The version number is not important information, because it is of no use to the customer.

I keep coming back to threads like this to see if anyone has given any good reason for knowing the current Cloud version, and so far, had nothing.  The answer "Cloud" is the only useful version.

David said it far better that I have:  this is a Cloud platform and the whole point of a Cloud platform is that software updates are transparent to you as the user. 

[Tom Lewis]

Who decides what is important?

The ability to see things from your customers’ point of view is one of the most essential customer service skills.

The whole point of any platform is to provide customers with functionality they request.

What standards are being leveraged in the development of Atlassian products?

Does Atlassian have a high security cloud platform like Azure does?

It is interesting that Atlassian provides version numbers for their self hosted software.

This thread has outlived its usefulness and the answer I get here is, you can use rest API but it is too much of a chore for the cloud dev team to just pop that into a Help>About dialog box for customers.

Thanks for clearing that up.  For anyone who cares about version control, here is what that rest API output looks like:

{"baseUrl":"https://ecosystem.atlassian.net","version":"1001.0.0-SNAPSHOT","versionNumbers":[1001,0,0],"deploymentType":"Cloud","buildNumber":100191,"buildDate":"2022-02-14T06:05:53.000-0600","scmInfo":"ebaa485c6e6ba9eae8f0cae9aead249194bbb82a","serverTitle":"Ecosystem Jira","defaultLocale":{"locale":"en_US"}}

[Nic Brough -Adaptavist-]

I think most of those questions are straying off topic and valuable questions to ask in their own right.  The original question was really "is there a number and why isn't it readily available in the UI".  The answer is "because it is of no use to you, the end-user".

That's what I've been focussed on - why?  What use is the version to the end-user?  They have no control over it, it doesn't tell you anything more than the static answer of  "We're on Cloud" does.  The responses I've seen to this have all been good reasons, but only for versions where you do have control over the version. 

And that answers one of the points here - The customer does have control over the server version.

[Tom Lewis]

“The Cloud” as we know is just someone else's server farm. The fact that we are using “the cloud” as a reason not to post the current version of software is just ignoring a request. Government compliance is one reason, transparency is another.  

[Tom Lewis]

https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom

[Nic Brough -Adaptavist-]

A Service is not part of an SBOM, so that's an irrelevance.

[Tom Lewis]

Page 16,

"...it is recommended that cloud service providers assert that they have an internal SBOM. That SBOM must be maintained with the rough functional equivalents of the minimum elements above, although the exact format and architecture may vary based on a provider’s internal system. The organization must also have the capability to act on this information and have a process to do so in a timely fashion. Over time, best practices will emerge to integrate SBOM data into third party risk management and supply chain risk management tools and processes. One use case that might be relevant for government agencies is forensic SBOM analysis: whether the cloud provider can determine whether or not a particular component was part of the deployed system at some time in the past."

[Nic Brough -Adaptavist-]

Nope, you're still missing the point there (and the legalese is complete junk).  You bought a service, not a product.

A friend I saw today is having a similar problem with one of their providers, to the point where there are lawyers involved.  They're laughing all the way to the bank because they're getting paid stupid amounts of money to write "the version of the service is irrelevant, you bought a service" repeatedly.

But he did have a good simple analogy.  When you get your car serviced by a mechanic, do you ask what their birthday is?

Whether your answer to that is yes or no, could you explain why it matters to your car getting serviced?

[Tom Lewis]

Ok Nic. All you've proven is that you seem to feel you know better than customers.

That analogy doesn't work. It is not comapring the right components.

It would be more of a quality thing like, you may want to know the version number of the air wrench used on your vehicle because it was found to overtighten lug nuts which caused them to break at high speed.

One scenario might be, upon recent upgrade to version ?? of Jira, the database lost a user story due to a database key mismatch and it caused the next iteration of a customer's software product to be void of an important customer requirement. So much so that they lost future contract awards.

I feel like this thread has outlived any meaningful outcome.  I won't be replying after this.  It is clear that you are inflexible on this topic.  Any customers that are willing to be out of the loop on what versions of support systems they employ when building their products are working at risk.  If we know anything about agile development, it includes frequent communication with customers.  If vendors continue to tell customers that their requests for information are invalid, how long do you think they will stay in business? (This is retorical, no response forthcomming.)

[Nic Brough -Adaptavist-]

The analogy works fine - remember you're buying a service, not running the software.

If you go to a mechanic to get your car serviced, you don't have any say in what tools they might use, or how old they are, and even if you did, you have no use for that information.

I'll also stop now.  You've still not been able to give us any reason for the customer knowing the version of Cloud, so there's not a lot of point.

[Bloompeak Support]

Version number can be retrieved via below rest api.

https://ecosystem.atlassian.net/rest/api/3/serverInfo

[Tom Lewis]

Thank you for the information.  Great that it is accessible from rest api.  For convenience and clarity, please post to the "About Jira" and all other Atlassian tools.  

[Royd Amias]

Knowing the version of any 3rd party sw being used helps with audits and root causing of issues found either internally or externally. It's a compliance thing.

[Nic Brough -Adaptavist-]

Please read the conversation above. 

The short version is that you are buying a service, not running a server.  The version of the servers behind the service are irrelevant to audits, issues and compliance, and all you need to tell auditors and compliance is that you are running "the latest version"

[Guilhem Dupuy]

Hello Guy,

I don't know exactly about this version number, which is very likely to exist even though it's not public, but I know this :

Jira Cloud is automatically updated for every user by Atlassian, hence every user from every instance, is working using the same "version number" of the Cloud version, which is the same for everyone at a given moment, independently of the company they are working for.

Hence, I don't know why you need this information for but as it is said in your quote, it's not a very "relevant" piece of information.

Keep me informed if it made your comprehension any clearer,

Guilhem

[Talya Yurman]

Hi,

As a Healthcare/Medical device company we should validate On the Shelf tools we use, also for our Quality Management, so it includes the JIRA.

Validation is done for intended use scenarios execute on a particular SW version. If JIRA cloud is updates recently without our control so this validation is not valid anymore.

Do you have any solution for that issue? can I freeze my cloud version? and sure need to know what version we are validating.

[MN]

Hi,

@Talya Yurman you are right about the "not valid validation". We do have helped medical device companies with validation and see some solutions there. In case you'd like to learn more contact us and we can have chat on the topic. So just drop me an email: margus@softcomply.com 

We have also had discussion with Atlassian about this version number and actually there isnt one. This ecosystem API is just one piece of the puzzle, since whole Atlassian ecosystem is larger than just this component. 

cheers,

Margus

SoftComply