This is a draft document that was built and uploaded automatically. It may document beta software and be incomplete or even incorrect. Use this document at your own risk.

Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Lifecycles of SUSE Linux Enterprise Components
SUSE Linux Enterprise Server 16.0

Lifecycles of SUSE Linux Enterprise Components

Publication Date: 24 Oct 2025
WHAT?

This article outlines how every SUSE Linux Enterprise 16 software package is assigned one of three specific update policies: stable, balanced or agile.

WHY?

To understand how package updates may affect system stability and compatibility.

EFFORT

No configuration is required; only awareness and planning are needed.

GOAL

You will have an overview of how SUSE categorizes packages.

1 Types of package life cycles

 

On SUSE Linux Enterprise 16, component packages are sorted into different lifecycle categories. This section describes the criteria for such a sorting.

When categorizing a package, the impact of its changes on the system is considered. To estimate this impact, the interfaces of the component must first be identified. For example, in the case of a shared library, changes to its API or ABI may disrupt the system. For a compiler or interpreter, disruptive changes may involve supported languages, command-line options, or the performance of the compiled code. By contrast, a minor backward compatible change may have little to no impact.

In general, a package falls exactly into one of the categories: stable, balanced, or agile. However, some technologies may have packages sorted into several categories, for example, Python. The following sections describe the package categories in detail.

1.1 Stable

 

Packages that are marked as stable* (also called conservative) are those that do not deliver a disruptive change while a customer is on any of the 16 minor versions. During the upgrade to another minor version, the package version may change but the newer version does not introduce incompatible behavior. Customers expect to have LTS on these packages.

The packages belonging to this category can change, but the following criteria apply:

  • changes in functionality are backward compatible: functionality can be added, but not removed

  • changes to interfaces are backward compatible

  • the default behavior of applications does not change unexpectedly

Under exceptional circumstances like serious security issues, the package can be updated even at the cost of bringing disruptive changes. Alternatively, if a new version of a package contains disruptive changes, this version can be delivered as an alternative to the previous one.

A typical example of a stable package is util-linux. Another is glibc, which remains backward compatible except for symbols deprecated upstream.

1.2 Balanced

 

Packages categorized as balanced are changing (driven by upstream evolution and customer demands), but should not cause disruptive changes within one minor version. A few incompatible changes are possible, but always documented in the release notes for that particular minor release.

Customers expect a moderate number of changes during the upgrade from a minor release. However, the transition must be smooth, either by getting back to the original behavior or by providing the older version in parallel with the new one.

When change is being introduced, it can be in one of the following ways:

  • A single version is provided with the minor release. The new version replaces the previous one while allowing for smooth transitions between the versions. New versions are released only with a new minor release.

  • Two versions are provided simultaneously. The new version is introduced in addition to the existing version, which then becomes obsolete with the next minor release.

Such versions are supported at least until the end of the LTS of the minor release that introduced them.

To help with incorporating changes in a conservative environment, the tick-tock model can be used. For example, we could mark even-numbered minor releases as tick releases and odd-numbered minor releases as tock. These tock releases could still introduce version updates in packages with a balanced lifecycle, but these updates remain fully backward compatible in all relevant aspects.

For ISVs, a stable runtime environment is critical. Therefore, not to break third-party applications, in the case of shared libraries where SUSE provides the corresponding -devel package, the older .so version is not deprecated immediately. For example, for a package called foo, there are packages: libfoo-0_1, foo-devel and foo-utils. If the package is updated and the shared library version changes to libfoo-0_2, libfoo-0_1 is not removed.

Typical examples of balanced packages include the following:

  • systemd: changes should be backward compatible; incompatible changes are documented in the release notes

  • kernel: the kernel is updated with each minor release

  • virtualization components: they are updated with each minor release

  • MariaDB: a new minor version with each minor release

  • PostgreSQL: upstream versions are released on a roughly annual basis, so the new version is introduced either with a minor release or as part of a maintenance update for an older minor release

  • Python: a version supported for a longer period of time with a set of modules on top

1.3 Agile

 

Packages categorized as agile are up to date with upstream even though they may bring incompatible changes to the system.

Updates to these packages are done in two possible ways:

  • With the release of a new package version, one or more older versions are supported for customers that cannot switch easily to the new version. There is a sliding window in which different versions are supported concurrently (for example, for version N and version N - 1). These concurrent versions are supported for a certain period of time that can differ from the lifetime of the minor release.

  • The package is just updated without support for the older version.

All new package versions are released simultaneously to all minor releases under general support and generally also in LTS.

The following packages are categorized as agile:

  • Go and Rust: a new version is released roughly every 6 months with a sliding window of 2 months.

  • GCC: a new version of the compiler is released with each minor release with a sliding window of 2. However, the libraries libgcc and libstdc++ are categorized as stable.

  • CLI and SDK for Public Cloud: a new version every quarter, and the new version replaces the previous one.

  • Python interpreter, library and pip: a new version is released annually.

  • Data files for time zones: a new version is released when a new set of definitions becomes available.

1.4 Package maintainer's FAQ

 
1. I want to define a lifecycle for my package. What should I do?

Raise a Jira ticket so we can track and document the process. If you are not sure about the lifecycle category, contact your manager and a SLE architect.

2. Which type of lifecycle can or should I adopt?

The further down in the stack your component is, the more packages depend on it, so you should take a more conservative approach. When in doubt, contact the SLE architects.

3. I want to use a balanced lifecycle for my package. Should I go for several versions in parallel?

In general, it is better to replace the old package with a new version. It creates less overhead on the maintainer side and is less confusing to customers. A sliding window is useful for most toolchain components that have API or ABI changes as part of new releases. However, the particular approach depends on the amount and type of changes. For example, if the changes can be adopted easily or even automated, then it is better to just update the package. When changes lead to conflicts that neither we nor the customer can easily resolve, then maintaining parallel versions is a better option.

SUSE tried this on a case-by-case basis for Python modules.

4. Should I convert my package from a balanced lifecycle to an agile one, and release updated versions also to code streams under LTS?

This is a question that we need to investigate in every case. In general, if the particular package is beneficial for customers on the older releases, then it may be worth releasing the updated packages to older releases. For example, if a component is mostly about operations, then it may be useful for customers on older releases. On the contrary, newer packages that provide hardware enablement are usually not needed, as customers' hardware has not changed since the time of installation.

2 Update strategy of desktop components

 

In general, desktop components follow the balanced lifecycle of their packages.

The SLE 16 desktop environment provides the following components:

GNOME desktop

The minimum version is 48.0. The exact version must be determined before the end of beta releases.

GStreamer, PipeWire and Flatpak

These components are updated to the latest stable branch version at the last beta release.

Firefox

The minimum version is 140.3. The update strategy follows the ESR update lifecycle.

WebKit

The minimum version is 2.46. WebKit has a periodic update cycle determined by critical CVEs. The component is updated but not backported.

BRLTTY

The accessibility tools are at the latest upstream stable versions in the 16.0. Only bug fixes will happen in this minor release.

QT

The Qt 6 is delivered. The initial version is Qt 6.9.

KDE

Not a standard SUSE Linux Enterprise delivery; available only in PackageHub 16.

3 Update strategy of toolchain components

 

The toolchain components include the following tools: the GNU C library, the GCC and G++ compilers, binutils, GDB and LLVM. Each of the component update strategies is described in corresponding sections.

3.1 GNU C library (glibc)

 

The initial glibc version is 2.40. The package is updated with each minor SLE release if there are reasons for changes to the package (for example feature requests, performance tuning and so on).

Package updates provide backward compatibility for dynamic linking, allowing programs built on previous SLE 16 releases to run. On the contrary, symbols deprecated in the upstream glibc version will not be declared for the compiler and not available for link editing (static linking). Such cases, when source level and static linking backward compatibility is not guaranteed, are properly documented.

3.2 Compiler for user space applications and libraries

 

Developers of user-space applications can use the supported GNU Compiler Collection (GCC) C and C++ built-in compilers. Compilers for other languages, cross-compilers and accelerator offloading compilers are not available on SLE from standard repositories, but developers can install them from Package Hub with community support.

The initial major version in SLE 16.0 and 16.1 is GCC 15. Later SLE releases will introduce the tick-tock model:

  • Each even minor release of SLE (the tick release) introduces a new major version of GCC. This GCC version is supported during the LTS for the minor version that introduced it and also for the next SLE minor version. For example, if GCC 17 is introduced in SLE 16.2, it will be supported until the end of LTS for SLE 16.3.

  • Each odd minor release of SLE (the tock release) comes with a new non-default major version of GCC. As this version is not the default one, you must explicitly invoke the binaries gcc-x, g++-x and gfortran-x to use it. These non-default versions are supported for 24 months.

3.2.1 Supported compiler flags

 

Any combination of the following compiler flags is supported:

  • -O0, -O2 and -O3

  • -ffast-math

  • -flto

  • -fpie and -fno-pie

  • -fPIC

  • -g

The following options are also supported on AMD64/Intel 64:

  • -march=x86-64-v2 (the default one)

  • -march=x86-64-v3

  • -march=x86-64-v4

Other compiler flags are not supported by SUSE. However, we can assist in reporting issues to the upstream GCC project.

3.2.2 Supported language versions

 

For the C language, the most recent supported version is ISO/IEC 9899:2024 (known as C23) with GNU extensions.

For C++, the most recent supported version is ISO/IEC 14882:2017 (known as C++17) with GNU extensions.

SUSE also provides unsupported packages with compilers for Fortran, Ada and Go (gcc-go).

3.3 The kernel module compiler

 

To build a kernel module, you need the same compiler version used to build the kernel. Therefore, SUSE provides the same GCC version—initially GCC 13.N.

The compiler for kernel modules is not intended for general use. The kernel module compiler may also be dropped in a future minor release of SLE.

3.4 The build compiler

 

There is a default compiler that is used internally to build SLE 16 packages in the version GCC 13. The build compiler is provided as an unsupported package in PackageHub.

Package maintainers can use the newer GCC available in the internal build service, but in this case, they must be aware of possible ABI issues (for example, avoid linking code written in different C++ standards).

3.5 GCC and C++ runtime libraries

 

GCC runtime libraries (libgcc, libstdc++) are updated to the versions of a new major version of GCC on a yearly basis in all SLE minor releases under LTS. The runtime libraries are updated during maintenance updates.

The runtime libraries are fully supported during the general support and LTS of each SLE minor version.

When security incidents may happen, these runtime libraries are the only part of the toolchain that can be used for that matter.

3.6 The GNU Binutils

 

The GNU Binutils are upgraded to the latest upstream version in all SLE 16 minor releases under general support of LTS.

3.7 The GNU project debugger

 

GDB is updated to the newest major version on all SLE 16 minor releases under general support or LTS. However, this means that certain functionality may be removed from the package.

3.8 LLVM

 

LLVM is available for use exclusively with MESA. Any other use of LLVM is not supported. Front-ends like Clang are not provided on SLE. You may get them only from a community-supported repository.

3.9 Compatibility and deprecation policy

 

SUSE maintains backward dynamic-linking compatibility for glibc and the C++ compiler runtime library. This means that a binary built on an earlier minor version of SLE 16 runs correctly on a later minor release.

Features deprecated by upstream are removed either from newer major versions of compilers or from all toolchain components in later SLE minor versions. In the case of glibc, the deprecated symbols are then removed from header files and are not available for link editing. Therefore, the code using these symbols will no longer compile or (statically) link.

3.10 Security considerations

 

Development tools like the compiler are not hardened to process untrusted input. In contrast, the GCC and C++ runtime libraries are the only parts of the toolchain that are hardened for this purpose.