cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

What's in a version number?

Product Manager

SolarWinds has a long history of being easy to try and easy to buy. Those of you who own two or more Orion Platform product modules may have realized, usually when planning your next upgrade, it's not necessarily easy to know which product module versions are compatible with others. While figuring this out may not be too terribly difficult when you own only two Orion product modules, the complexity rises significantly with each additional product module you purchase thereafter. Imagine you need to figure out which versions of your other 13 Orion Platform product and integration modules are compatible with Server & Application Monitor 6.7? Suddenly, what was previously a rather trivial task has become a daunting, and sometimes overwhelming, challenge.

For that reason and many more, we have some significant changes coming your way to end the madness. First though, here’s a brief history of where we've been, how we got here, and where the future will take us.

The Matrix

For many years, we attempted to make the process of deciphering compatibility between Orion Platform product modules easier through a compatibility matrix maintained within our documentation. The matrix itself was a fairly complex Excel spreadsheet that oftentimes felt like you needed a secret decoder ring to help interpret the results. For what you might imagine should be a relatively simple task, the compatibility matrix was anything but.

Upgrade Advisor

As the number of available Orion Platform product modules increased, we eventually realized the Compatibility Matrix had become too complex for customers to interpret, and too unwieldy for us to maintain. Thus came our next valiant attempt at improving the situation for determining multi-product compatibility, the Upgrade Advisor. The Upgrade Advisor represented a monumental leap forward compared to the Compatibility Matrix. In fact, many still rely upon it today.

The process is relatively straightforward. Enter in the Orion Platform product modules you currently have installed and their respective version numbers. Next, enter the version number of the product module to which you'd like to upgrade. The Upgrade Advisor will then map out the rest of the product module version numbers compatible with the newer version.

While fraught with good intentions, the Upgrade Advisor still suffered from the same fundamental flaw which led to the demise of the Compatibility Matrix. It still required users to be both aware of its existence and proactive about their upgrade planning. When the recommendations outlined in the Compatibility Matrix or Upgrade Advisor weren't followed, bizarre and unexplainable issues would occur due to incompatible module behavior.

Next Generation Installer

The latest attempt at unraveling this quagmire has been to place the information available in the Upgrade Advisor into the installer itself. Anytime before or at the time of upgrade, simply running the installer provides a list of all Orion Platform product modules currently installed and their respective versions. Next to it is the list of versions for other product modules compatible with the module version downloaded.

Image result for solarwinds installer upgrade

This method is vastly superior to both the Compatibility Matrix and Upgrade Advisor, as it requires no prior knowledge of the existence of either, nor does it require any manual steps to determine module compatibility. The installer simply handles it all for you. No muss, no fuss.

While the next-generation installer took all the complexity out of the equation, it introduced a fair amount of confusion. For the planners among you, it seemed counterintuitive to run an installer, days, weeks, or even months ahead of a scheduled upgrade to determine the upgrade path. For others, executing the installer on a production environment prior to the scheduled change window sounded like a dangerous proposition, assuming the mere fact of running the installer might start the upgrade process or shut down Orion services without consent or confirmation. As a result, some still found greater comfort utilizing the Upgrade Advisor this new installer was intent on replacing.

Does this really need to be so complicated?

A lot of time, effort, and different technologies have been used throughout the years in what seems to have been a vain attempt to reduce confusion and make it easier for users to identify compatibility between different product module versions. The problem, however, was never how we attempted to address the issue (though admittedly, some methods worked better than others). The ultimate solution is to change how we think about the problem in the first place: the version number itself.

Ushering in a new tomorrow

It's rather arbitrary that 6.9 is the Server & Application Monitor (SAM) version compatible with Network Performance Monitor (NPM) 12.5. Rather than require users have a Ph.D. in SolarWinds Orion Platform product module versioning, wouldn't it be easier if those product modules compatible with each other all shared the same version number? Then it would be downright simple to identify IP Address Manager vX.XX wasn't compatible with User Device Tracker vY.YY or Network Configuration Manager vZ.ZZ.

Simplifying and consolidating our product module versioning is precisely what we aim to do in our next Orion Platform module releases. As you can imagine, this might come as a big surprise to many, which is why we've decided to notify the community in advance.

New releases for every Orion Platform product module going forward will now use the same versioning as the Orion Platform itself. This means the next release of Network Performance Monitor will not be v12.6 or v13.0, nor will any of the other Orion Platform product modules bear a resemblance to their current versioning. Instead, Orion Platform product module versions will be the four-digit year in which they were released, followed by the quarter of release. If there is a Service Release for a given module, it will appear in the third position following the quarter.

[YYYY.Q.SR]

If this all seems a bit confusing, fret not. You're probably already familiar with this versioning, as it's been the basis of the Orion Platform version for nearly a decade. This is also the same versioning used for Network Automation Manager.

pastedImage_7.png

What does this mean for my product modules?

To be completely honest, really nothing at all, aside from a departure from those products’ previous versioning schemes. It also means versioning is much more transparent and easier to relate to. For example, if you needed to know what version of Storage Resource Monitor (SRM) was released in October 2025, it’s now very easy: Storage Resource Monitor v2025.4. If you also needed to know what version of Server Configuration Manager (SCM) was compatible with SRM v2025.4, that too is now easy: SCM v2025.4, of course!

How will this affect previous releases?

In short, it doesn't. Currently released product module versioning will remain unchanged, though you can expect a fairly significant jump in version numbers the next time you upgrade.

I still have unanswered questions

You undoubtedly have a million questions related to this change racing through your brain right now. If not, perhaps later, after pondering this post for a while, a fantastic question pops to mind. In either scenario, post your questions related to this change in the comments section below.

28 Comments

It's been an interesting ride, upgrading since 2004.  I'm happy to have had something fun and reliable to monitor and manage our network nodes and their configs.

MVP
MVP

Bah, now I and my team will have to find how to spend those hours each month, previously dedicated to working through the various upgrade path options that should/could be taken. We need to wait until everyone is on 2019.4 as the base point, but until then, we can continue to use our finely honed skills using the upgrade adviser and dealing with its many quirks.

Yay, one less secret decoder ring to have to keep around! Will miss all of the Ovaltine, though.

ovaltine.jpg

Level 11

was there an exam coming?  I have all these notes here and was hoping for a test. maybe a quiz?

Product Manager
Product Manager

Maybe we'll talk to DanielleH​ about making this a monthly mission

Level 12

Does that mean all products will have to be upgraded at the same time? I assume there will be some backwards compatibility between the latest Orion version and a product that can't be upgraded at the same some for some reason?

Level 12

I should have also commented... I love this direction!

Product Manager
Product Manager

Yes, it has always been a requirement that all product modules be upgraded. This was not properly enforced early on, which caused a lot of issues for customers that encountered compatibility issues after selectively upgrading only some of their modules. This was later properly enforced with the new installer that requires that all modules be upgraded to compatible versions.

Level 20

I like the way you lay stuff out and document the changes aLTeReGo​... you've always done a good job mixing some text with pictures to make it easy to understand.  Props for that!

Product Manager
Product Manager

I'm glad you enjoyed the read ecklerwr1​. My only disappointment was I was unable to find a screenshot of the horrid Compatability Matrix. That would have been a great blast from the past and would have reminded everyone just how hard things used to be.

Product Manager
Product Manager

Just for fun - here is a snapshot of that atrocity - brings back nightmares...

pastedImage_0.png

So how will this work with modules that are upgraded part-way through a year?

So we have 2019.4 right now, but if another product hits GA before the end of the year will it be 2019.5? 2019.x? Just trying to wrap my head around the idea of being Orion core 2019.4 if a module is on 2019.5, for example. Or are all modules going to be on the same release schedule?

I'm still happy to see this happen though, version numbers have been all over the place.

Product Manager
Product Manager

Great question designerfx​! The scenario you describe should not occur as all modules should be releasing together with the Orion Platform, further bringing order to the chaos.

Level 14

There are upgrades ?      

Level 12

MI BRANE HURTZ

Level 12

Thanks for the article and the work to bring order to the chaos.

I have had some trouble recently with identifying my products using the 2019.x versions as displayed in the WebUI and the version numbers we need to select when opening ticket (ACM 6.9, NPM 12.5).  A few of the support reps seem less than amused trying to translate them as well.  hopefully this is a short term growing pain as the versions get standardized to a new format.

Level 10

And Remember that you needed to correlate that with Windows OS and SQL versions too! And still make it match up across every single module.... Then a hotfix or new version went GA a couple of days prior to the much much much planned upgrade, but the matrix was not updated.  I recall early versions of the upgrade advisor and the matrix not agreeing, and calling support to get a third, different, but final answer.

can say that I am  VERY HAPPY with the current installer. If it could only make espresso while we wait for the install to complete.

Level 10

aLTeReGo​ - so this means that products which dont see many updates (like WPM) will get a version nudge with every orion upgrade now? If so- thank you as that will make upgrades easier to plan.

Product Manager
Product Manager

marcrobinson  wrote:

aLTeReGo  - so this means that products which dont see many updates (like WPM) will get a version nudge with every orion upgrade now? If so- thank you as that will make upgrades easier to plan.

Yes, that is correct.

Product Manager
Product Manager

Well the installer can't make espresso (yet), as a consolation, there is a hidden video game easter egg in the installer for those that can find it

MVP
MVP

Very Cool.

Level 9

Great looks, will make things very clean and easy to understand going forward.

Overall, this is a good change, but as I have to wear all the hats in my business, I can also see the potential negative impact this may have elsewhere.

On the engineering side, consolidating the version numbers with that of the Orion Platform is great. It will demystify much of the upgrade process for the layman, which from personal experience is historically a large pain point for existing customers. There will still be the environmental blockers to deal with when upgrading (OS and SQL Server versions, mostly), but other than using the admin bell in Orion itself to warn people of this when new versions are available which their current environment does not support, there isn't much else SWI can do. Kudos all round there!

Where this change will hurt is marketing. Being able to promote a traditional incremental version number is a lot easier (and widely recognised) than what we're moving to, for example NPM 12.6 will now be referred to as NPM 2019.4 (assuming it gets a general availability release before Christmas). Not everyone will understand this naming convention for module versions, and it'll have people scratching their head, especially for those punters who are not programmers (where xxxx.y.z are fairly common versioning naming conventions). While continuous development and obfuscation of version numbers is being more widely adopted (even Microsoft is doing it!), it's still alien to a large percentage of potential customers. People like their version numbers, it is a way the human psych associates value with a thing.

However, for people with maintenance, Orion really is just on big continuously developed platform, so it's a logical change.

For the professional services providers among us, we can help SWI get the message out but advising our clients of this change. The more exposure this gets, the more widely known it'll be, and the less impact it'll have. So I'll be doing my part, I encourage my professional services peers to do likewise

Product Manager
Product Manager

That's a very astute observation jezmarsh​ Indeed there is a perception problem with versioning that's difficult to overcome because every software company versions differently. In far too many cases the version number is more or less arbitrary and does not accurately reflect the significance of each release. While many companies consider the first significant digit to represent a major release, SolarWinds has historically avoided reving this too often for a wide variety of different reasons.

I can't tell you how many trade shows or customer events I attend where customers believe they're 'current' with their release (12.0), or only slightly behind (11.5) because of the version number. NPM 12.0 for example, was released back in 2016. There have been enormous improvements in that product over the course of those three years. However, perception from customers still running many years of releases behind is that they are still relatively current, or running just a little behind. In this respect, SolarWinds lighting fast release cadence can be both a blessing and a curse when customers end up getting too far behind.

Absolutely agree with the pitfalls of letting an Orion platform go stale.

Going from 12.1 to 12.4, for example, is a whole new ball game. New minimum OS versions for application servers, new SQL Server versions for the database side.... there's a lot of potential pain there for people unfamiliar with the current pace of releases, who are waiting for NPM 13.0 before they upgrade, or in the new parlance NPM 2020.x, / 2021.x

Please don't wait longer than YourVersion+2 before you upgrade, folks, else you may find the path strewn with many, many, pitfalls and potentially extended platform downtime to apply your upgrades. You are entitled to them, as part of your maintenance purchase, so there really is no good reason to get too far behind. Not applying updates is literally a waste of money.

Disclaimer: I recommend, unless you absolutely must have one of the new features available in the bleeding edge release versions, you stick to General Availability Version -1 for your modules. That way you get the benefit of a mature module, with hot fixes to patch any coding adventures that existed in the initial releases, and are protected from any new voyages in coding discovery that may come with the latest and greatest at day one.

Level 10

Another ditto to silverbacksays​ on the version and upgrade advice. 12.0 to 12.4 is a huge change in version. Also - the new installer is LEAPS and BOUNDS ahead of the older manual upgrade method. The thoughts on keeping one version behind, and waiting for the hotfixes to drop before upgrading, is also recommended. For those sitting on the fence, the stability of upgrades starting after 12 is improved. Just please pay attention to the os/sql requirements AND recommendations, as that will stop many headaches. The documentation is well worth reading.  (Yeah I know - RTFM.)

Level 16

i would welcome this change.. it would make it easier and will have uniformity among all production version numbers...

Level 7

Thanks for the informative breakdown.