SUSE Linux Package Lifecycles and Strategy

Stable (also called conservative) packages do not deliver a disruptive change while a customer stays on any 16.x minor release. 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 (Long Term Support) on these packages.

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

Under exceptional circumstances, such as serious security issues, a package can be updated even at the cost of bringing disruptive changes. Alternatively, a version with disruptive changes 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.

Balanced packages change, driven by upstream evolution and customer demands, but must not cause disruptive changes within one minor release. A few incompatible changes are possible, but they are always documented in the release notes for the respective minor release.

Customers expect a moderate number of changes during the upgrade from a minor release. The transition must be smooth, either by restoring 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:

Versions are supported at least until the end of the LTS phase 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, even-numbered minor releases are tick releases and odd-numbered minor releases are tock releases. Tock releases can still introduce version updates for balanced packages, but these updates remain fully backward compatible in all relevant aspects.

For ISVs (independent software vendors), a stable runtime environment is critical. Therefore, to avoid breaking third-party applications, the older .so version is not deprecated immediately when SUSE provides the corresponding -devel package. 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:

Agile packages are kept up to date with upstream, even if this brings incompatible changes to the system.

Updates to these packages are done in two ways:

All new package versions are released simultaneously to all minor releases under General Support and, generally, also in LTS.

Typical examples of agile packages include the following:

The Apache HTTP Server Project maintains stable release branches, identified by even-numbered minor versions. Within a stable branch, upstream designs revisions to remain compatible to the maximum possible extent. This applies to the module API, the runtime configuration and the compile-time configuration (the configure options supported by one revision remain supported by later ones). Features may be added, and features may be deprecated with appropriate documentation. This compatibility-oriented policy is what allows SUSE to update Apache regularly during General Availability (GA) without introducing disruptive changes.

Note

Upstream compatibility does not constitute an unconditional guarantee for every third-party module, local customization or deployment configuration. Verify new Apache package versions with your particular configuration and module set before deploying updates in production.

For Apache in SUSE Linux 16.0, SUSE maintains the stable update strategy, which combines a rolling-style update approach during GA with a more conservative approach during LTS.

The LTS freeze does not prevent an exceptional version update when one is required. In particular, SUSE retains the option of performing an emergency version update when necessary to address a critical security vulnerability or other exceptional requirement.

Most container components follow an agile lifecycle model, aligning closely with upstream project releases. This applies to general container infrastructure packages, including runc, docker, podman and their respective ecosystems, as well as helm.

Packages trail corresponding upstream project releases with an intentional buffer window reserved for enterprise hardening, security auditing and integration testing.

Updated versions are released across all supported SUSE Linux 16 codestreams, including versions under LTSS (Long Term Service Pack Support). If a new upstream major version introduces severe backward-incompatible changes, SUSE defers its introduction until the next minor release.

For environments that need extended release predictability without feature version bumps, SUSE provides a dedicated docker-stable package.

On SUSE Linux 16, Go and its components are updated and supported according to the following rules:

When building applications, developers have the following options regarding versions:

Alongside standard go1.xx releases, SUSE provides a parallel go1.xx-openssl variant. This version is specifically patched to use OpenSSL for FIPS-compliant cryptographic operations.

Starting with go1.24, Go upstream introduced an integrated FIPS 140-3 cryptographic implementation. As this implementation achieves certification, the parallel go1.xx-openssl variant will be deprecated in favor of the upstream-supported FIPS mechanism. SUSE packaging follows the upstream deprecation schedule and support lifecycle.

The HA stack is divided into core clustering components and cluster storage components.

SUSE Linux Enterprise 16.0 includes several Python interpreter versions with different support lifecycles:

SUSE Linux Enterprise 16.0 follows a defined release and support schedule for Python interpreter versions.

In SUSE Linux Enterprise 16.0, the System Python is Python 3.13. The current plan (subject to change) is to provide newer Python versions in future SUSE Linux Enterprise 16.x releases.

A Developer Python version will be released with each minor release and will be supported only for the general support period of that release (two years).

The following security components follow the stable life cycle and remains the same within the same minor version. New versions are typically introduced only to the next minor release:

The following security components follow the balanced life cycle and can be updated with a maintenance update or get version update with releasing a new minor release:

The following security components follow the agile life cycle and are kept up-to-date with upstream:

The initial glibc version is 2.40. The package is updated with each minor SUSE Linux 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 SUSE Linux 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).

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 SUSE Linux from standard repositories, but developers can install them from Package Hub with community support.

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

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 SUSE Linux.

There is a default compiler that is used internally to build SUSE Linux 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).

GCC runtime libraries (libgcc, libstdc++) are updated to the versions of a new major version of GCC on a yearly basis in all SUSE Linux 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 SUSE Linux minor version.

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

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

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

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

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 SUSE Linux 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 SUSE Linux 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.

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.

SUSE Linux 16.0 provides a modern virtualization stack centered around KVM and QEMU. The primary shipped components and their initial baseline versions in SUSE Linux 16.0 include: