Share with friends and colleagues on social media



This is the fourth blog of a series in which we will provide some insight into SUSE Linux Enterprise product development. You will get a first-hand overview of SUSE, the SLE products, what the engineering team do to tackle the challenges coming from the increasing pace of open source projects, and the new requirements from our customers, partners and business-related constraints.

How SUSE builds its Enterprise Linux distribution:

Whether you are a long-term SUSE customer, a new SUSE customer, a SUSE partner, or just an openSUSE fan or open source enthusiast, we hope you will find these blogs interesting and informative.

Let’s take a look back on how we have planned the cadence of our releases in the past up until now for the SLE 12 and SLE 15 code streams.

If you are wondering why there are only 3 public pre-releases for SLE 15 SP2, please read the “Changes to our pre-releases” section of SLE 15 SP2 Public Beta Program announcement.

Release Cadence and Tick-Tock Model

As you can see, since SUSE Linux Enterprise 12, we have released a service pack every year regularly. The same still applies to SUSE Linux Enterprise 15. Since predictability is a common request from many of our customers and partners, we provide them with roadmaps. For a reminder to everyone, the exact FCS dates can be found at https://www.suse.com/lifecycle/.

Another important aspect shown in the table above, is that SLE is using the Tick-Tock model, however we generally refer to it as the “Consolidation/Refresh” model.

What does this mean? To put it simply:

Tick – odd versions – Consolidation

Bug/Security fixes from maintenance updates,

Improvements for existing features,

Feature parity between SLE 15 and SLE 12,

Selected new features,

Tock – even versions – Refresh

All from Tick-Release

Kernel version bump

Stack upgrade

The Tick-Tock model is consistent throughout the release cycle of a code stream. The last service pack of a code stream is definitely a “Consolidation Service Pack”, simply because the purpose of our Service Pack Model is to guarantee steadiness and stability, which is especially important to our customers who need to migrate to the next major version, and for this we would need a solid ground to do so.

Therefore the last service pack of SLE 12, which is SLE12 SP5 is a Consolidation Service Pack.

Last but not least, the Tick-Tock Model is a principle, i.e it’s a “guideline” for the SLE Team and should be regarded as a “theme” for our users perspective.

Let’s get concrete with an example: we have to choose a specific Linux Kernel version for a given service pack. For instance, SLE 12 SP1 was marked as Consolidation with Kernel 3.12.49 (at FCS), SLE 12 SP2 was marked as Refresh with Kernel 4.4.21 (at FCS). So it is clearly visible that we used the Refresh Service Pack to jump to a major new Linux Kernel version.

However:

Is SLE 12 SP1 (kernel 3.12.49) lacking some driver support brought in with the upstream kernel version 4.4?

No. Not only is it our job to make sure that we use stable Linux Kernel, but also it is our job to make our products ready for new hardware, which our customers might have bought. So we are “backporting” Linux Kernel features per customers’ and partners’ requests to our Linux Kernel version.

Are all the shiniest and fresh features brought in with the upstream kernel version 4.4 supported in SLE 12 SP2?

No. Not all of these features will meet our quality standards and therefore we would mark these as Technology Preview in order to make them available for testing. The next Service Pack, SLE 12 SP3, marked as Consolidation, would likely enable these features as fully supported.

And that’s just two examples out of many, showing that Flexibility is the key. Both SUSE and our users will always value stability and enhancement, and so applying the Tick-Tock Model is never black and white.

Therefore we always recommend that you read our Service Pack Release Notes to get more details and important information about changes such as new and/or deprecated* features and Technology Previews, which would likely come with both Consolidation and Refresh Service Packs.

*When we deprecate a feature we announce it one Service Pack before the deprecation is effective.

Development and Maintenance in parallel

In the Support and Lifecycle section of SLES 15 SP1 Release Notes, the following is stated: “[…]SUSE Linux Enterprise Server 15 has a 13-year life cycle, with 10 years of General Support and 3 years of Extended Support. The current version (SP1) will be fully maintained and supported until 6 months after the release of SUSE Linux Enterprise Server 15 SP2.[…]“. Therefore there would be a 6 month overlap period when both SP1 and SP2 would be supported. Since our engineers are dedicated to maintaining and developing packages and/or technologies and not specific versions of our products, this means that any given engineer would have to maintain packages in parallel across several Service Packs.

On top of this, in 2019 while SLE 12 SP5 and SLE 15 SP1 were both in development, both SLE 12 SP4 and SLE 15 were being supported and bug-fixed at the same time. So our SLE Engineers have to continue maintaining their released materials while working on upcoming versions.

As a matter of fact, general terms for development and maintenance, which are commonly used in open source projects, are derived from the generic code branching model:

“ Dev ” branch where all the exciting new development happens. Usually not supported at all.

” branch where all the exciting new development happens. Usually not supported at all. “ Stable ” branch which usually receives only bug and security fixes. Supported for limited amount of time.

” branch which usually receives only bug and security fixes. Supported for limited amount of time. “Long Term” branch where only important and critical fixes are considered. Extend the support time for older versions.

In theory this is a simple model, which gives everyone (engineering and users) a framework of what to expect and what to deliver for any given branch.

Of course at some point in time the “Dev” branch can be “froze” to become a new Major Stable branch.

SLE is following a similar approach although more complex, given that we have 2 Major Versions, each having their “Development/General Support/Extended Support (LTSS)” phases and their respective internal “Dev/Stable/Long Term” branches. There is also one last branch to consider, which of course is the “upstream” branch: openSUSE.

But for the moment, let’s just consider that we have a total of 7 branches for SLE, when we are supporting 2 Majors Versions in parallel ((Development + General Support + LTSS)* 2 + upstream).

How does this work in real life? Well we will try to explain this in future blog posts.

Further Readings:

Share with friends and colleagues on social media



(Visited 1 times, 1 visits today)