We often get asked what is the recommended code level that a client should use. While this isn’t as difficult a question as anything performance related, I’m afraid the answer still often starts with “it depends” !

V.R.M.F – Version Release Maintenance Fix

First off its worth ensuring you understand the code numbering. Everything Spectrum Virtualize uses the VRMF standard for version naming. Until now, the VRM part has been fairly abitrary, or more to the point, they changed in a fairly arbitrary manner! The V, major version would be changed when a significant licensing change to the products occurred, or we release a substantial new feature or product range. The R and M were incremented again, almost in a sort of arbitrary manner.

However, with the new Continuous Development release model, the value of M is now important.

F, the Fix level, or often referred to as the PTF number should be thought of as a post-fix to the version ( in all meanings of the word ) – in that an F update only ever includes fixes to critical or field found issues that have been detected post release of the VRM version, and any previous PTF levels at that VRM.

Writing i something like VRM(F) would make it easier, as your version is VRM and your fix level is F.

The simple way to look at the F is – I should always use the highest available F version for my VRM. Ideally, upgrading to the new F when its released (not always possible or easy) but certainly when moving up to a new VRM always use the latest F for that VRM.

Formalisation of Long Term Support (LTS) Versions

For a few years we have been talking about certain cover versions being “golden” or “hardened” code versions. These were versions that IBM would recommend for someone wanting to minimise risk, at the expense of picking up the latest features and functions. For example, 7.8.1 and 8.2.1 would have been in this category, but it started getting complex, as we only announced 8.2.1 as hardened as of 8.2.1.6 etc

In order to simplify things, the development team are now working in a Continuous Delivery release model. Starting with version 8.4.0, the code releases will be split into two branches.

Long Term Support (LTS)

• Contains new functionality in addition to all functionality introduced in previous LTS and Non-LTS releases.
• Plan for quarterly fix packs (PTFs) but no new functionality will be added, to deliver maximum stability.
• Plan for one LTS release every 1-2 years.
• Identified by a zero as the third digit of the release number (e.g. 8.4.0.0) (The M)
• IBM expects the majority of customers to run the LTS branch.
• Select this branch if stability is the priority.

Non-Long Term Support (Non-LTS)

• Contains new functionality in addition to all functionality introduced in previous LTS and Non-LTS releases.
• Will not receive any fix packs.  Fixes for issues introduced in a Non-LTS release will be delivered in a subsequent Non-LTS or LTS release,
• Plan for multiple Non-LTS releases per year.
• Identified by a non-zero as the third digit of the release number (e.g. 8.4.1.0) (The M)
• To upgrade to a Non-LTS, a system must already be running a previous release (LTS or Non-LTS) on the same version.  For example, to upgrade to 8.4.2 the system must be running 8.4.0.x or 8.4.1.  To upgrade from 8.4.2 to 8.5.2 the system must first be upgraded to 8.5.0.x,
• Select this branch if new functionality is the priority.

Example Timeline

To show this in some more detail, here is an example of how this may pan out :

A few key things to note.

A new “planned” LTS release does not become instantly “recommended” as soon as it is released. At some point after enough field run-time and proven stability, it will be marked as recommended.

If you upgrade to a Non-LTS version to pickup new features, be aware that you may need to plan to update more regularly, i.e. to the next Non-LTS version as that is the only delivery vehicle planned for fixes that would normally be included in PTFs.

The FAQ has some answers to commonly asked question.

Further Information

The current recommended versions landing page.

Detailed explanations and FAQ for LTS and Non-LTS Continuous Delivery

For reference : Code Compatibility Matrix, Latest Versions, Hardware Compatabiliy