This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
Maybe we should start off by clearing up at least one bit of confusion around Liberty z/OS. On z/OS Liberty is part of the WebSphere Application Server for z/OS product. That product includes both WebSphere traditional and Liberty. WAS z/OS is supported in two versions: V8.5.5 and V9.0.5. Contained in those different versions of WAS are different versions of WebSphere traditional. But…here’s the confusing part..Liberty is exactly the same whether you’re licensed for WAS z/OS V8.5 or V9. So no matter which version of WAS z/OS you have, you’re using the same Liberty.
WebSphere traditional in V8.5.5 gets updated every six months and V9.0.5 gets updated every three months (at least as I’m writing this). Those updates change the fourth qualifier in the version (i.e. 8.5.5.22 and 9.0.5.12).
Liberty, on the other hand, still within the same WAS z/OS product, either version, gets updated twelve times a year. The version numbers for Liberty are the two-digit year followed by two zeroes and then the level within the year. So 2023 starts with level 23.0.0.1, then four weeks (roughly) later will see 23.0.0.2, and so until near the end of the year you’ll see 23.0.0.12 followed by 24.0.0.1 the following January. The number at the end does kinda-sorta-mostly correspond to the month, but not always. It depends how the four week intervals match up to the calendar (and how tight we stick to the four week interval).
I want to emphasize that these levels are not ‘versions’ in sense that you have to plan a big migration effort. While new function can (and usually does) show up in each new level, it is also the delivery mechanism for ongoing service updates that fix problems and (occasionally) close integrity holes.
There are rules about how far back you can be and still get a fix created and rules about what levels automatically get fixes created for integrity issues. I’m not going to rehash those here in case they change. I’m also not going to link to it because that stuff has a way of moving. The guidance at the moment is to generally stick to the levels divisible by 3 (i.e. 22.0.0.3, 22.0.0.6, 22.0.0.9, and 22.0.0.12). The in-between levels are just fine and you might need to move to one to get a new feature you need sooner.
Another concern is how far behind to lag. People often like to lag a bit behind to avoid running into new problems in recently delivered levels, but don’t lag too far behind because you’re either having to request fixes be created for integrity problems or just not getting them. You need to determine your own risk levels and requirements, but a decent starting point might be to lag one divisible-by-three level back from the front edge. So if you’re on the .3 version for some year, wait ‘till the .9 version comes out to move to the .6. You’re not on the very front edge, but you’re not too far back either. Adjust based on your own needs of course.