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 content
SUSE Linux Package Lifecycles and Strategy
SUSE Linux 16.1

SUSE Linux Package Lifecycles and Strategy

Publication Date: 09 Oct 2026

SUSE Linux component package lifecycles define the update and support strategies for software packages across SUSE Linux 16 product lines. By categorizing software into stable, balanced or agile lifecycle models, SUSE balances long-term system stability with timely upstream feature updates and security patches. This framework allows system administrators and developers to anticipate update impacts, maintain application compatibility and plan enterprise deployments across general support and long-term service support phases.

1 Types of package lifecycles

On SUSE Linux 16, component packages are sorted into different lifecycle categories. This section describes the criteria for the 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 a shared library, changes to its API or ABI (application binary interface) 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 has little to no impact.

In general, each package belongs to exactly one category: 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

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:

  • 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, 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.

1.2 Balanced

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:

  • A single version is provided with the minor release. The new version replaces the previous one and allows a smooth transition. 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.

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:

  • systemd: Changes are backward compatible. Incompatible changes are documented in the release notes.

  • kernel: Updated with each minor release.

  • MariaDB: A new minor version with each minor release.

  • PostgreSQL: Upstream releases roughly annually. The new version is introduced with a minor release or as part of a maintenance update for an older minor release.

  • System Python: The primary system interpreter and its associated modules remain stable and supported throughout the product lifecycle.

1.3 Agile

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:

  • With the release of a new package version, one or more older versions remain supported for customers who 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 that can differ from the lifetime of the minor release.

  • The package is 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.

Typical examples of agile packages include the following:

  • Go: A new version roughly every six months, with versions N and N-1 supported.

  • Rust: A new version roughly every six weeks, with versions N and N-1 supported.

  • GCC: A new version with each minor release. Versions introduced in odd minor releases are not the default and have a shorter support period. See Section 25.2, “Compiler for user space applications and libraries” for details. The libraries libgcc and libstdc++ are described in Section 25.5, “GCC and C++ runtime libraries”.

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

  • Python interpreter, library and pip (Developer Python): A new version annually.

  • Time zone data files: A new version whenever new definitions become available.

2 Ansible update strategy

Ansible is an open source IT automation engine that simplifies provisioning, configuration management, application deployment and orchestration by using a human-readable, agentless language.

Lifecycle category

Agile

Release cycle

Per component, see Table 1, “Ansible components and release frequency”

Support scope

On SUSE Linux, the Ansible interpreter and the Linux system roles are supported. On SLES for SAP, the SAP roles and playbooks are supported as well. Support covers only the roles and playbooks delivered by SUSE.

Table 1: Ansible components and release frequency
ComponentPackagesRelease frequency
Ansible interpreteransible, ansible-core Twice a year (typically May and November)
Linux System Rolesansible-linux-system-roles Frequently
SAP roles and playbooksansible-sap-install, ansible-sap-infrastructure, ansible-sap-operations, ansible-sap-playbooks Irregularly
Unsupported SAP rolesansible-sap-launchpad Irregularly

3 Apache HTTP server update strategy

The Apache HTTP Server (Apache) is a feature-rich, open source Web server. In SUSE Linux 16.1, Apache follows the stable lifecycle model. This model balances the delivery of security fixes and other relevant upstream changes with the compatibility and long-term stability expected from SUSE Linux systems.

3.1 Upstream compatibility policy

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

3.2 Update strategy and lifecycle model

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

Lifecycle model

Stable

GA phase

For SUSE Linux minor releases in GA, the Apache package is upgraded when a new upstream Apache version is released. New upstream versions are typically released several times per year.

LTS phase

When a SUSE Linux minor release enters LTS, the Apache version is frozen. Version upgrades are avoided during LTS unless they are considered necessary. Potential version upgrades are evaluated on a case-by-case basis, taking into account security, maintenance and compatibility requirements.

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.

4 Cockpit update strategy

Cockpit is a Web-based graphical interface that enables you to manage most administration tasks from one place.

Cockpit follows a balanced lifecycle strategy and is updated and supported according to the following rules:

  • Each SUSE Linux minor release comes with the latest Cockpit version.

  • Support for this version continues throughout the entire lifecycle of the minor release, with any necessary fixes provided through backports.

Note
Note

SUSE may upgrade to a newer version when reasonable, for example, for bug fixes, security updates or usability improvements, especially during LTS.

5 Container components update strategy

Container technologies evolve rapidly upstream. To provide timely enhancements, security fixes and ecosystem compatibility while maintaining enterprise stability, container components use two strategies: an agile approach for standard components and a long-term stable model for one Docker option.

5.1 Agile lifecycle model for container ecosystems

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.

5.2 Long-term stable Docker option (docker-stable)

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

Lifecycle model

Stable (pinned major and minor release)

Version alignment

Pinned at a specific major and minor release. The same version is delivered across all codestreams.

Support phases

Supported and maintained for three years from its release date.

Lifecycle transition

A new version of docker-stable is released at the end of the three-year support period.

6 Desktop components update strategy

In general, desktop components follow the balanced lifecycle. The individual components differ, as shown below.

Table 2: Desktop components
ComponentVersionLifecycle categoryUpdate rule
GNOME desktop48.0BalancedUpdated with bug fixes and compatible minor point releases within the GNOME 48 stream.
GStreamer, PipeWire, FlatpakLatest stable releaseBalancedUpdated via maintenance updates for bug fixes and security patches within the shipped stable branch.
FirefoxMinimum 140.3Balanced (ESR)Follows the Mozilla Firefox ESR (Extended Support Release) update lifecycle.
WebKitMinimum 2.46AgilePeriodic update cycle driven by critical CVEs; updated to newer upstream releases rather than backporting fixes.
BRLTTYLatest upstream stable in 16.1StableMaintained with bug fixes only during this minor release lifecycle.
QtQt 6, initial version 6.9BalancedUpdated with bug fixes and backward-compatible minor updates aligned with minor releases.
KDE—N/ANot a standard SUSE Linux delivery. Available only in PackageHub 16.

7 Go update strategy

Go is an open source, statically typed, compiled programming language designed for building reliable and efficient software.

7.1 Lifecycle and support policy

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

Lifecycle category

Agile

Release cycle

In sync with upstream, which nominally releases every six months, in February and August. Updates are integrated within a two-month sliding window following each upstream release.

Supported versions

Versions N and N-1, mirroring the upstream support policy. When a new major version is released, the oldest supported version enters a two-month sliding grace period for transition before retirement.

Minor releases

Go minor releases are made available shortly after the upstream release.

Parallel installation

Supported. Versions are parallel installable and undergo automated testing. The go metapackage always points to the latest go1.x package.

Support phases

General Support and LTS for all relevant SUSE Linux minor releases

7.2 Building Go applications

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

Latest recommended version

Depend on a minimum version, for example, BuildRequires: golang(API) >= go1.23.

Controlled timing of build changes

Pin a specific go1.x package, for example, BuildRequires: golang(API) == go1.23.

Minimum version

In both cases, use the go1.x version given in the go directive of the application's go.mod file, because the Go compiler now requires it as a minimum version.

7.3 FIPS compliance

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.

8 High Availability update strategy

The High Availability (HA) extension stack in SUSE Linux 16 provides mission-critical clustering, resource management, automated fencing, Web-based management and cluster storage services.

8.1 HA stack components

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

Table 3: HA core stack
PackageDescription
pacemakerHigh-availability cluster resource manager
corosyncCluster engine providing infrastructure messaging and membership services
sbdSTONITH Block Device for node fencing using shared storage
resource-agentsOpen Cluster Framework (OCF) resource agents for managing cluster services
fence-agentsFencing agents for power control and node isolation
crmshCluster management command-line interface
hawkHigh Availability Web Konsole (Hawk) for cluster management and monitoring. Requires Ruby, see Section 19, “Ruby delivery strategy”.
Table 4: HA storage stack
PackageKernel integrationDescription
drbd-kmpOut of treeDistributed Replicated Block Device (DRBD) kernel module, managed outside of the kernel tree
drbd-utilsUserlandUserland management utilities for DRBD
lvmlockdUserlandLVM lock daemon for clustered LVM volumes (subpackage of lvm2)
gfs2-kmpIn treeGlobal File System 2 (GFS2) kernel module, part of the kernel tree
gfs2-utilsUserlandUserland utilities for managing GFS2 file systems
cluster-md-kmpIn treeClustered Multi-Device RAID kernel module, part of the kernel tree

8.2 Update policy and lifecycle rules

Lifecycle category

Balanced

Supported versions

Only one active package version is maintained per SUSE Linux 16 minor release.

Release cycle

Package versions are updated across minor releases to synchronize with the latest stable upstream releases.

In-tree kernel modules

The kernel-module packages integrated into the kernel tree (gfs2-kmp and cluster-md-kmp) follow the kernel tick-tock version update model.

Out-of-tree and userland storage components

The out-of-tree kernel module (drbd-kmp) and the userland storage tools (drbd-utils, lvmlockd and gfs2-utils) are updated in alignment with stable upstream releases and kernel compatibility updates.

Support phases

Supported throughout General Support and LTS as part of the SUSE Linux Enterprise High Availability extension

9 Java update strategy

On SUSE Linux 16, Java is delivered in several versions that are maintained independently of the minor release cycle.

Lifecycle category

Agile

Supported versions

See Table 5, “Java versions and support end dates”

Parallel installation

Supported. Different Java versions can be installed concurrently.

Release cycle

Java versions are maintained independently of the SUSE Linux minor release cycle, and Java packages can be updated in an agile manner.

Support phases

Each version is supported throughout General Support and LTS.

Table 5: Java versions and support end dates
VersionSupported until
Java 17December 2027
Java 21October 2031
Java 25October 2033

10 libpng update strategy

libpng is the official reference library for supporting the Portable Network Graphics (PNG) image format. It is a fundamental graphical component used across desktop environments, image processing utilities and multimedia frameworks in SUSE Linux.

The libpng package follows the balanced lifecycle model across all SUSE Linux 16 products. The update strategy is governed by the following rules:

Lifecycle category

Balanced, across all SUSE Linux 16 products. This permits updating to new upstream patch releases to deliver security fixes, bug fixes and performance improvements, while safeguarding application compatibility and soname stability.

Compatibility

Upstream libpng maintains strict ABI compatibility within active release series. Updates are patch-level version bumps that keep the same soname, so downstream applications and graphical libraries do not break or need rebuilds.

Supported versions

For every libpng series that remains in upstream maintenance, the latest patch version is delivered to all supported SUSE Linux 16 minor releases as it becomes available.

11 man-pages update strategy

The man-pages package provides the primary reference documentation for Linux system calls, C library functions, device files, file formats and system administration conventions.

Lifecycle category

Balanced, across all SUSE Linux 16 minor versions

Release cycle

With each new SUSE Linux 16 minor release, man-pages is updated to the latest upstream version.

Kernel and API alignment

The primary objective of these periodic version updates is to keep documentation in sync with new kernel updates, system call modifications and C library (glibc) enhancements introduced in each minor release.

12 MariaDB update strategy

MariaDB is a high-performance, open source relational database management system (RDBMS) that was created as a community-developed fork of MySQL to ensure the software remains free and accessible under the GPL license.

Lifecycle category

Balanced. Only upstream LTS MariaDB releases are supported.

Versions

Each minor release gets a new MariaDB version. The starting version is 11.4.5.

Support phases

Each version is supported for the General Support and LTS periods of its minor release.

Minor version updates

Aligned with upstream releases and provided exclusively for the mariadb and mariadb-connector-c packages.

13 Network UPS Tools update strategy

Network UPS Tools (NUT) is an open source software suite that supports power devices, such as uninterruptible power supplies (UPS), power distribution units and controllers. It simplifies monitoring of power hardware and ensures orderly system shutdowns during power outages.

Lifecycle category

Stable, with on-demand updates. Newer upstream versions maintain strict backward compatibility, so upgrades do not introduce disruptive changes for customers on any 16.x minor release.

Update drivers

Because upstream versions are backward compatible, updates are driven by new features that are difficult or impractical to backport, mainly support for new hardware such as new UPS models.

Scope of updates

When a new version with valuable features is available upstream, the packages are updated across all supported codestreams in General Support and maintenance.

Flexible maintenance delivery

The upstream release schedule is irregular, so new versions are submitted as they are released. They are delivered within a new minor release or as maintenance updates for already released codestreams.

14 node.js update strategy

Node.js is an open source, cross-platform JavaScript runtime environment for building server-side applications outside of a Web browser. It is built on Google Chrome's V8 engine and uses an event-driven, non-blocking I/O model, making it highly efficient for creating scalable network applications.

Lifecycle category

Agile

Versions

The version is kept in sync with the upstream LTS version. Each minor release provides the latest Active LTS version (see Node.js previous releases), starting with nodejs 22, and ships it as the default.

Minor releases

Upstream minor and patch updates for active Node.js streams are delivered via maintenance updates, primarily triggered by upstream security releases or upon request.

Parallel installation

Supported. Different node.js versions can be installed in parallel.

Support phases

Versions in a minor release are supported until the end of LTS.

Building applications

To use the most recent recommended version in the repository, use BuildRequires: nodejs >= 22.

15 Perl update strategy

Perl is a high-level, general-purpose programming language, originally developed for text manipulation, that is now used for system administration, Web development and network programming.

Lifecycle category

Stable

Versions

The version shipped with the initial release remains fixed throughout the SUSE Linux 16 lifecycle. Maintenance updates deliver bug and security fixes only, with no major version upgrades planned.

16 PHP update strategy

PHP is an open source server-side scripting language designed for Web development. It is used to create dynamic, interactive content that works with databases.

Lifecycle category

Balanced

Versions

The starting version is 8.4. A new PHP version is shipped with each SUSE Linux 16 minor release.

Release cycle

Patch-level updates are delivered throughout the support period of each minor release.

17 PostgreSQL update strategy

PostgreSQL is an open source object-relational database management system (ORDBMS) known for its reliability and its support for advanced data types and complex queries.

Lifecycle category

Balanced

Supported versions

All versions maintained by the upstream community.

Release cycle

When upstream releases a new version, it is added to each minor release under General Support or LTS.

Parallel installation

Supported. Multiple PostgreSQL major versions can be installed side by side on the same system.

End of life

SUSE support for a PostgreSQL version ends concurrently with upstream end of life. Once a version reaches upstream EOL, it remains in the repositories for migration purposes but receives no further security patches or bug fixes.

18 Python update strategy

SUSE Linux 16.1 includes several Python interpreter versions with distinct support lifecycles. Rather than applying a single blanket classification, each Python interpreter stream is categorized individually based on its update model.

18.1 Python interpreter lifecycles

Table 6: Python interpreters
InterpreterCategorySupported duringDescription
System PythonStableGeneral Support and LTS of 16.1, and of each future 16.x minor releaseThe version for which SUSE provides a large set of Python modules needed for applications and solutions. The version and its modules remain stable throughout the lifecycle.
Developer PythonAgileGeneral Support only, excluding LTS (two years)A more recent Python version, intended for use with Python wheels from PyPI, installed and maintained through pip and pipx.
Legacy PythonStableGeneral Support and LTS of the minor release in which it is providedProvided in future 16.x releases when System Python moves to a newer version. The previous System Python and all its modules remain supported for compatibility.

18.2 Python release cycle

System Python

Python 3.13 in SUSE Linux 16.1. The current plan, which is subject to change, is to provide newer System Python versions in future 16.x releases.

Developer Python

A new Developer Python version is released with each minor release and is supported only for the General Support period of that release (two years).

19 Ruby delivery strategy

The Ruby stack is not delivered as a standard component of SUSE Linux 16.

However, specific components that depend on Ruby include it as a supported dependency.

Lifecycle category

Not applicable. Ruby is supported only as a dependency of the components below.

Hawk

Part of SUSE Linux Enterprise High Availability. It is built on Ruby on Rails and requires a Ruby runtime.

RMT (Repository Mirroring Tool)

Requires Ruby. Ruby is provided as a supported exception.

20 Rust update strategy

Rust is a multi-paradigm, general-purpose programming language designed for performance and safety, especially safe concurrency.

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

Lifecycle category

Agile

Release cycle

In sync with upstream, which releases every six weeks

Supported versions

Versions N and N-1

Upgrade window

Six weeks, to perform upgrades and find potential issues

Parallel installation

Supported. Parallel installable versions are available and undergo automated testing.

Support phases

General Support and LTS for all relevant SUSE Linux minor releases

21 Security components update strategy

This section defines the update policy and lifecycle strategy for core security components in the SUSE Linux 16 codestream.

21.1 Stable security components

These components remain the same within a minor release. New versions are typically introduced only with the next minor release.

OpenSSL

The version is fixed for FIPS 140-3 certification within the minor release.

GnuTLS, Nettle

The version is fixed for FIPS 140-3 certification.

libgcrypt

The version is fixed for FIPS 140-3 certification.

OpenSSH

Remote login and communication protocol toolset; maintained with bug and security fixes within the minor release.

liboqs, oqs-provider

Post-quantum cryptography library and OpenSSL provider; maintained with bug and security fixes within the minor release.

GnuPG

OpenPGP encryption and signing toolset; maintained with bug and security fixes within the minor release.

krb5

Kerberos authentication protocol implementation; maintained with bug and security fixes within the minor release.

Smartcards and U2F tokens

Hardware authentication middleware and libraries (such as OpenSC, pcsc-lite, and libfido2); maintained with bug and security fixes within the minor release.

IMA tools

Integrity Measurement Architecture management utilities; maintained with bug and security fixes within the minor release.

openCryptoki

PKCS#11 implementation for hardware security modules; maintained with bug and security fixes within the minor release.

rage

Modern file encryption tool and Rust implementation of the age format; maintained with bug and security fixes within the minor release.

rsign2

Digital signature utility and Rust implementation of minisign; maintained with bug and security fixes within the minor release.

PAM stack, polkit

Pluggable Authentication Modules and PolicyKit authorization framework; maintained with bug and security fixes within the minor release.

21.2 Balanced security components

These components can be updated with a maintenance update or receive a version update with a new minor release.

firewalld

Updated with compatible minor and patch releases during maintenance updates or new minor releases.

SELinux

Policies are updated with monthly snapshots.

Network Security Services (mozilla-nss)

Initial versions establish the baseline for FIPS 140-3 evaluation. Maintenance updates align with Firefox ESR releases to deliver compatible security and protocol updates.

strongSwan

New versions are typically introduced with a new minor release.

Stunnel

Updated with compatible point releases during maintenance updates or new minor releases.

TPM libraries and tools

Trusted Platform Module software stack and utilities; updated with compatible point releases during maintenance updates or new minor releases.

21.3 Agile security components

These components are kept up to date with upstream.

Cosign, Rekor

Kept up to date with upstream.

ClamAV

Kept up to date with upstream.

scap-security-guide

Kept up to date with upstream.

ca-certificates-mozilla

Updated when a new NSS certificate bundle is released.

22 smartmontools update strategy

smartmontools (S.M.A.R.T. Monitoring Tools) is a software suite for controlling and monitoring storage systems using the Self-Monitoring, Analysis and Reporting Technology (S.M.A.R.T.) built into ATA, SATA, SCSI, SAS and NVMe hard drives and solid-state drives. It plays a critical role in early disk failure detection and hardware monitoring.

Lifecycle category

Stable, with on-demand updates. Upstream versions maintain strict backward compatibility, so updates do not introduce disruptive changes to system configurations, script integrations or reliability.

Update drivers

New hardware enablement and support for new drive models. Updates are driven by features and hardware support requested by customers that are difficult or impractical to backport.

Scope of updates

When a new version with useful features or new hardware support is available upstream, the packages are updated across all supported codestreams in active maintenance.

Delivery

The upstream release schedule is irregular, so new versions are submitted as they are released. They are delivered within a new minor release or as maintenance updates for already released codestreams.

23 sudo update strategy

sudo (Superuser Do) is a critical system administration utility that allows permitted users to execute commands as a superuser or another user according to security policy. It is a foundation for privilege management, access control and audit logging in SUSE Linux 16.

Lifecycle category

Balanced. This balances system stability with timely maintenance fixes, security hardening and upstream bug fixes.

Release cycle

With every new minor release, sudo is updated to a newer patch release. This delivers cumulative stability and security updates while preserving configuration and workflow compatibility.

24 Time zone update strategy

Data files for time zones follow the agile lifecycle.

Lifecycle category

Agile

Release cycle

When a new set of time zone definitions becomes available, the package is updated across all supported SUSE Linux systems.

Supported versions

Only the latest version. The package is updated without ongoing support for older versions, the same approach as in SLE 15.

25 Toolchain components update strategy

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

25.1 GNU C library (glibc)

Lifecycle category

Stable

Versions

The initial version is 2.40. The package is updated with each minor release if there are reasons for changes, for example feature requests or performance tuning.

Compatibility

Updates are backward compatible for dynamic linking, so programs built on earlier SUSE Linux 16 releases keep running.

Deprecated symbols

Symbols deprecated in upstream glibc are not declared for the compiler and are not available for link editing (static linking).

25.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 SUSE Linux from standard repositories. Developers can install them from PackageHub with community support.

Lifecycle category

Agile, with the tick-tock model described below.

Initial version

GCC 15 in SUSE Linux  16.1. The tick-tock model applies to later releases.

Tick releases (even minor releases)

Introduce a new major GCC version as the default compiler. It is supported during LTS of the introducing minor release and of the next minor release. Example: GCC 17, introduced in 16.2, is supported until the end of LTS of 16.3.

Tock releases (odd minor releases)

Include a new non-default major GCC version. To use it, invoke the binaries gcc-x, g++-x and gfortran-x explicitly. Non-default versions are supported for 24 months. In 16.1, this is GCC 16, invoked with gcc-16, g++-16 and gfortran-16.

25.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. SUSE can assist in reporting issues to the upstream GCC project.

25.2.2 Supported language versions

C

ISO/IEC 9899:2024 (C23) with GNU extensions

C++

With the default GCC 15: ISO/IEC 14882:2017 (C++17) with GNU extensions. With the non-default GCC 16: ISO/IEC 14882:2020 (C++20) with GNU extensions.

Fortran

Up to Fortran 95 (ISO/IEC 1539:1997), with specific features from later standards as described in the manual.

25.3 Kernel module compiler

Purpose

Building a kernel module requires the same compiler version that was used to build the kernel. SUSE therefore provides that GCC version, initially GCC 13.N.

Restrictions

The compiler is not intended for general use and may be dropped in a future minor release.

25.4 Build compiler

Version

SUSE Linux 16 packages are built internally with GCC 13. This build compiler is provided as an unsupported package in PackageHub.

Notes

Package maintainers can use the newer GCC in the internal build service, but must be aware of possible ABI issues, for example, by avoiding linking code written in different C++ standards.

25.5 GCC and C++ runtime libraries

Lifecycle category

Stable (libgcc, libstdc++)

Release cycle

Updated yearly to the versions of a new GCC major version, in all minor releases under LTS. Updates are delivered as maintenance updates.

Support phases

Fully supported during General Support and LTS of each minor release.

Security

These runtime libraries receive maintenance and security updates because they are dynamically linked by running user-space applications. They are hardened for processing untrusted input and are available for use when addressing security incidents.

25.6 GNU Binutils

Release cycle

Upgraded to the latest upstream version in all SUSE Linux 16 minor releases under General Support or LTS.

25.7 GNU project debugger

Release cycle

Updated to the newest major version in all SUSE Linux 16 minor releases under General Support or LTS.

Compatibility

Certain functionality may be removed when GDB is updated to a newer major version.

25.8 LLVM

Scope

LLVM is available exclusively for use with Mesa. Any other use is not supported.

Front-ends

Front-ends such as Clang are not provided. They are available only from a community-supported repository.

25.9 Compatibility and deprecation policy

Dynamic-linking compatibility

SUSE maintains backward dynamic-linking compatibility for glibc and the C++ compiler runtime library. A binary built on an earlier SUSE Linux 16 minor release runs correctly on a later minor release.

Deprecated features

Features deprecated by upstream are removed either in newer major versions of compilers or from all toolchain components in later minor releases.

glibc symbols

Deprecated symbols are removed from header files and are not available for link editing. Code that uses them no longer compiles or links statically.

25.10 Security considerations

Development tools

Development tools such as the compiler are not hardened to process untrusted input.

Runtime libraries

The GCC and C++ runtime libraries are the only parts of the toolchain hardened for this purpose.

26 util-linux update strategy

util-linux is a standard suite of essential system utilities central to Linux system administration, storage management, hardware detection and core operating system operations.

Lifecycle category

Stable

Release cycle

Updated to the latest upstream release with each new SUSE Linux 16 minor release. This continues the maintenance practice established in SLE 15.

Compatibility

Upstream releases maintain strict backward compatibility (approximately 99%), so updates do not disrupt administrative workflows, scripts or core operations.

Rationale

Security patches and bug fixes can be backported, but customers frequently need new utility features, flags and hardware capabilities that are difficult or impractical to backport. Delivering updated upstream versions provides them.

27 Valkey update strategy

Valkey is a high-performance data structure server for key/value workloads. It supports a wide range of native data structures and an extensible plug-in system for adding new data structures and access patterns.

Versions

Kept in sync with upstream (see Valkey releases). Each minor release has the latest available version.

Release cycle

Backward-compatible Valkey minor releases are published promptly after the upstream release. Patch updates are delivered continuously to minor releases as soon as they are released.

Support phases

General Support and LTS of all SUSE Linux 16 minor releases.

Exceptions

Security fixes are backported if upstream does not issue a new release that includes the fix.

28 Vim update strategy

Vim (Vi IMproved) is an advanced text editor providing comprehensive text editing capabilities and extensive plug-in support.

Lifecycle category

Agile, with a flat version model. This continues the strategy established in SLE 15.

Release cycle

When a new upstream release is available, vim is updated to the latest version across all supported SUSE Linux 16 minor releases. active minor releases and those in LTS.

Supported versions

Only the latest version. Support for the older version ends when the update is released.

Rationale

Vim has an active upstream codebase, so deploying the latest release keeps patches easy to apply and issues straightforward to resolve.

29 Virtualization components update strategy

This section documents the lifecycle management and update strategy for virtualization components in SUSE Linux 16.

29.1 Included components and target versions

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

  • KVM: Inherited directly from the Linux kernel lifecycle

  • QEMU: Version 11.0.4 (updated in subsequent minor releases)

  • libvirt: Version 12.4.0, with VM confinement enabled by default using SELinux

  • open-vm-tools: Version 13.1.0 (updated in subsequent minor releases)

  • snpguest: Version 0.10.0, with remote and local attestation as a technology preview

  • virt-top: Version 1.1.1

  • virt-manager: Version 5.1.0, with direct XML editing via virsh and VNC viewing recommended

  • Hyper-V: Version 9 guest enlightenments and drivers (kernel)

29.2 Lifecycle model and update policy

Lifecycle category

Balanced

Release cycle

Every new minor release is updated to the latest upstream versions of all supported virtualization packages.

Support phases

All SUSE Linux 16 minor releases, throughout General Support and LTS.

Maintenance updates

In exceptional cases where packages maintain strict backward compatibility, version updates can be delivered within an already released minor release through maintenance updates.

Security

Security fixes are backported as necessary when upstream does not promptly issue a point release that contains the fix.

Quality assurance

Automated testing covers all key enterprise use cases across critical combinations of host and guest operating systems.

30 Wireshark update strategy

Wireshark is an open source network protocol analyzer used for network troubleshooting, analysis, software and communications protocol development and education. Because Wireshark parses a wide array of complex network protocols, it frequently receives updates for security vulnerabilities (CVEs) and protocol support.

Lifecycle category

Balanced. This balances strict stability with timely security patching and protocol analysis capabilities.

Maintenance releases (X.Y.Z)

Delivered continuously within SUSE Linux 16 minor releases and for previously released minor releases in maintenance. They contain security fixes and bug repairs only, with no new or changed features.

Minor versions (X.Y.0)

Updated with a SUSE Linux 16 minor release when a new upstream stable branch is selected for SUSE Linux. Such updates can introduce new protocol dissectors and features.

Major versions (X.0.0)

When upstream releases a new major version, SUSE evaluates case by case whether to transition. Any transition is documented in the release notes.