So, confession time. I normally like to have a post written in advance of a release so that I have time to go back to it with fresh eyes and edit it. This week however, I haven’t been able to figure out what to post. I originally thought about doing something around dressing up your instance for Halloween, but then I remembered something very, VERY important. I’m going to be brutally honest with both myself and you for a moment…
I am VERY terrible at web design…
This is perfectly alright. When I go to brand (or rebrand) a JIRA instance, I’ll usually reach out to Marketing or the website team, coordinate with them on color palette, and try out several variations. I’ve even been known to mock up a few palettes, put together a poll, and put it to a user vote. Your users have to use this platform every day. They should have some say in how it looks.
BUT – maybe this is not a lesson I’m qualified to write up…at least not yet. But this left me a day away from post time and no article. Then, while downloading a new version of JIRA for a test I was running, I noticed this:
A new JIRA release – but not just any kind of release – but an Enterprise Version.
So, why should I care about an Enterprise Release?
To understand this, first we need a bit of a history lesson.
While at VMware, we were fortunate enough to have both Atlassian TAMs and Premiere Support from Atlassian. I cannot speak highly enough of these teams – without them and learning from them, I don’t think I’d have gotten as far as I have as an Atlassian Admin.
One of the key benefits of Premiere Support is something called a Health Check. You would be able to submit your Support Zip to the team at Atlassian, and they’d take a look at it and see if there are any changes or tuning adjustments you can make to improve performance. This quickly allowed our instances to become some of the best maintained and performing instances inside VMware.
It became our policy to submit a health check prior to any upgrade we planned to make sure we were on a good footing. Often during our health check, Premiere Support and our TAMs would advise us of what they considered “Blessed” versions. That is, versions of their software that had undergone testing by Premiere Support and were considered stable enough to recommend to large enterprise clients.
Shortly before I left VMware, this concept morphed into an Enterprise version. This version was something of Atlassian’s take on Long Term Support versions. The plan is that any bugs will be backported to this Version.
What do you mean? Isn’t a version a version?
Eh – this gets sticky if you haven’t worked in software.
Software versions are something of a code. Lets take Atlassian’s releases. They often are encoded with three numbers separated by a period. For example: 8.5.0
The first number, Eight, in this is the Major or API Version number. In most software companies, they don’t increment this unless they have made major architectural changes – in lay mans terms that is to say they pretty much rewrote major parts of the code. That is why going from v1 to v2 is a big deal for them.
For Atlassian, a change in this number means they have made changes to either the underlying JAVA API or the REST API. When this changes is when I start worrying whether plugins or integrations will break. They can break on other releases, sure, but they are more likely to break when this changes.
The second number, five, is Feature Release Number. When this changes is usually when Atlassian will add new features to their products. This can sometimes either break or render obsolete plugins, but as I said that is more likely when the API Version changes. This is typically what I mean by version.
The third and final number, zero, is the Bug fix number. This is when Atlassian will fix bugs in their products, but add no new functionality. This is where the magic in Enterprise Releases comes in. For Enterprise releases, any bug fixes Atlassian makes for future versions that also affect the Enterprise Release, Atlassian will back port to the Enterprise Release. That is why most Atlassian releases will only get to a bug fix number of 3 or 4, but Enterprise releases will get to a bug fix number of 10 or 11.
This also gets to my advice about never installing software ending in Zero. These versions have not had a bug fix release yet, which means they are statistically more likely to have bugs than other versions. Don’t get me wrong, ALL software has bugs, but at least those not ending in zero have had some fixed.
Bug fix releases are also *generally* safer upgrades than Feature Releases or API Releases. That is to say, going from 8.5.0 to 8.5.1 is *generally* safer than going from 8.4.x to 8.5.0 or 7.6.6 to 8.5.0. HOWEVER, never trust things as infallible, and always test your upgrades in a pre-production environment.
But I’ve seen Atlassian back port security bugs to non Enterprise Releases? What’s up with that?
Yes, this is true. Some bugs are so insidious, so dangerous to security that Atlassian will do the work to back port them to as many versions as are still supported. You should always pay attention to Security Advisories and plan your upgrade cycles accordingly. But that being said, for an Enterprise Release you’re also going to get other bug fixes on top of the security ones, so why not go with that?
Is that the only benefit?
Not. Even. Close. Atlassian will also do performance testing on their Enterprise Releases, and tell you the result.
This can help you in your decisions around scaling and whether an upgrade is worth it. You might even be able to use this to sell the upgrade to your user base. I have yet to meet the user who didn’t appreciate a faster JIRA.
They also prepare an REST API Change log so if you are hopping from Enterprise Release to Enterprise Release, you can prepare your integrations for the upgrade that much easier
Also, to prevent you from going page by page to collect all the changes from previous versions, they also do a full change log between Enterprise releases here.
So, yeah, Enterprise Releases. They really are a good thing.
Every upgrade is a decision. Sometimes you have to have a new feature or bug fix and cannot wait until they next Enterprise Release to get it. It happens – I’ve been there. That being said, for the long term support you get, if you are limited on upgrade cycles, you don’t have a lot to lose by going with an Enterprise Release. So it’s definitely something to consider as you are going through the release notes to figure out a target version.
So for next week I’m still not sure what to write about either. However, I did have an interesting challenge on LinkedIn from last week’s post that I’m honestly considering…
That might be interesting. I still have the VM I did that on, so it might be a thing. Until then, My name is Rodney, asking “Having you updated your JIRA issues today?”
The Jira Guy 
3 Comments