By Yee-Kang Chang and Carolyn Carpenter
WebSphere Liberty follows a continuous delivery model and we have successfully delivered various new features and capabilities in this manner over the last few years. For example, this is how we have delivered Java EE 7 support in Liberty – starting with selected features in 2014 and culminating in full support for the whole platform and certification in the middle of last year. That was for WebSphere Application Server Version 8.5.
Now, with the release of WebSphere Application Server Version 9, we are taking it a step further and sticking with a single service stream for Liberty fix packs, shared by 8.5.5 and 9.0.0, that will be continuously delivered. Let us explain what this means.
Traditionally, new functionality is released in large chunks as a new product version, with smaller updates and fixes being delivered as fix packs in between versions. This means if you want to try out a new technology, you might have to wait a few years until the next version. With the Liberty model, new functionality is continuously delivered as modular optional features on top of the runtime, so there is no need to patiently wait for the next big version – just until our next regular update. You adopt the features you want when you are ready and because zero-migration is designed in, you can fully embrace continuous delivery and painlessly move up to a new level.
Single fix pack delivery stream
Because new versions no longer deliver a large amount of new function, the focus is all on the fix packs. With single-stream fix pack delivery, regardless of whether you purchased WebSphere Application Server Version 8.5 or Version 9, you get the same Liberty fix packs with the latest and greatest updates on the same schedule. This starts with fix pack 184.108.40.206.
Year-based numbering scheme
Fix pack 220.127.116.11? Huh? Where does this number come from? With the single-stream continuous delivery model, major version boundaries are no longer as significant. We are introducing a new fix pack numbering scheme to highlight what is important – how recent your Liberty installation is.
Instead of the traditional
version.release.modification.fix pack numbering scheme, such as
18.104.22.168, Liberty fix packs now begin with the year the fix pack is released. For example,
22.214.171.124 refers to the second fix pack of 2016, the first being
126.96.36.199, which was still on the old numbering scheme. The first fix pack of 2017 will be
188.8.131.52. In 2018, you can look at your
184.108.40.206 installation and know that it is about a year old, and it might be time to update.
So, it will be
Y.R.M.F or rather
Y.0.0.F from now on, where:
Y= year, last 2 digits
F= fix pack release during the year
When it is time to update, the Liberty zero-migration architecture means that you do not have to worry about reworking your server configuration or applications.
The server configuration is fully backward (and forward!) compatible, meaning that configuration for a newer release works with older releases, and an older configuration works with the latest release. Simply ensure that the configured features are correct and present and that is it. Any items that do not apply to a particular server are just ignored.
Liberty packages API support for your application in pluggable features, which you can enable and disable to customize the technologies available in your server. If an API changes, such as Servlet 3.0 to Servlet 3.1, you can continue to use the
servlet-3.0 feature and do not have to rework your applications to account for any behavior changes unless you choose to enable the later specification level.
Continuous delivery, single fix pack delivery stream, year-based numbering scheme, zero-migration architecture – combined together, they allow us to deliver the latest and greatest innovation to you in a clear and consistent manner with quality. It will always be the same Liberty that you get, so you can easily adopt the new technologies and move at a pace that suits you.
To 220.127.116.11 and beyond!