This section uses several terms. To understand the information, read the definitions below:

SUSE has the following product lifecycle:

SUSE supports previous service packs for six months after the release of the new service pack. Figure 1.1, “Major releases and service packs” depicts some mentioned aspects.

Figure 1.1: Major releases and service packs #

  

If you need additional time to design, validate and test your upgrade plans, Long Term Service Pack Support can extend the support you get by an additional 12 to 36 months in 12-month increments. This gives you a total of 2 to 5 years of support on any service pack. For details, see Figure 1.2, “Long term service pack support”.

Figure 1.2: Long term service pack support #

  

For more information, refer to https://www.suse.com/products/long-term-service-pack-support/.

Refer to https://www.suse.com/lifecycle for more information about lifecycles, release frequency, and the overlay support period.

For a list of modules, their dependencies, and lifecycles, see the Article “Modules and Extensions Quick Start”.

SUSE Linux Enterprise Desktop can regularly check for changes in the support status of all installed products and send the report via e-mail in case of changes. To generate the report, install the zypper-lifecycle-plugin with zypper in zypper-lifecycle-plugin.

Enable the report generation on your system with systemctl:

> sudo systemctl enable lifecycle-report.timer

The recipient and subject of the report e-mail, and the report generation period can be configured in the file /etc/sysconfig/lifecycle-report with any text editor. The settings MAIL_TO and MAIL_SUBJ define the mail recipient and subject, while DAYS sets the interval at which the report is generated.

The report displays changes in the support status after the change occurred and not in advance. If the change occurs right after the generation of the last report, it can take up to 14 days until you are notified of the change. Take this into account when setting the DAYS option. Change the following configuration entries to fit your requirements:

MAIL_TO='root@localhost'
MAIL_SUBJ='Lifecycle report'
DAYS=14

The latest report is available in the file /var/lib/lifecycle/report. The file contains two sections. The first section informs about the end of support for used products. The second section lists packages with their support end dates and update availability.

The range for extended support levels starts from year 10 and ends in year 13. These contain continued L3 engineering level diagnosis and reactive critical bug fixes. With these support levels, you will receive updates for trivially exploitable root exploits in the kernel and other root exploits directly executable without user interaction. Furthermore, they support existing workloads, software stacks, and hardware with limited package exclusion list. Find an overview in Table 1.1, “Security updates and bug fixes”.

¹ For further information on the SUSE Linux Enterprise Update Policy, refer to the following knowledgebase article.

On registration, the system receives repositories from the SUSE Customer Center (see https://scc.suse.com/) or a local registration proxy like SMT. The repository names map to specific URIs in the customer center. To list all available repositories on your system, use zypper as follows:

# zypper repos -u

This gives you a list of all available repositories on your system. Each repository is listed by its alias, name and whether it is enabled and will be refreshed. The option -u gives you also the URI from where it originated.

To register your machine, run SUSEConnect, for example:

# SUSEConnect -r REGCODE

To deregister your machine, you can use SUSEConnect too:

# SUSEConnect --de-register

To check your locally installed products and their status, use the following command:

# SUSEConnect -s

If you need to identify the version of an SLE installation, check the content of the file /etc/os-release.

A machine readable XML output is available with zypper:

> zypper --no-remote --no-refresh --xmlout --non-interactive products -i
<?xml version='1.0'?>
<stream>
<product-list>
<product name="SLES" version="15" release="0" epoch="0" arch="x86_64" vendor="SUSE" summary="SUSE Linux Enterprise Server 15" repo="@System" productline="sles" registerrelease="" shortname="SLES15" flavor="" isbase="true" installed="true"><endoflife time_t="0" text="0"/><registerflavor/><description>SUSE Linux Enterprise offers [...]</description></product>
</product-list>
</stream>

Upgrades between two major releases of SUSE Linux Enterprise Desktop are supported by SUSE. Whether it is better to upgrade or perform a fresh installation depends on your specific scenario. While upgrades involve less work, fresh installations ensure you benefit from all the new features of a release such as disk layout changes, specific file system features, and other improvements. To get the most out of your system, SUSE therefore recommends fresh installations in most scenarios.

In both cases—upgrade as well as a fresh installation—customers need to check if system settings and default values still fit their requirements.

For updates from one service pack of a specific release to another one of the same codestream, SUSE recommends to do it in-place, and not to perform a fresh installation. Nevertheless, there may be reasons and scenarios for a customer to perform a fresh installation in this case, too. The decision as to which is more suitable can only be made by the customer.

Before you perform any migration, read Chapter 3, Preparing the upgrade.

Important: Cross-architecture upgrades are not supported

Cross-architecture upgrades, such as upgrading from a 32-bit version of SUSE Linux Enterprise Desktop to the 64-bit version, or upgrading from big endian to little endian are not supported!

Also, since SUSE Linux Enterprise 15 is 64-bit only, upgrades from any 32-bit SUSE Linux Enterprise 11 systems to SUSE Linux Enterprise 15 and later are not supported.

To make a cross-architecture upgrade, you need to perform a new installation.

Note: Skipping service packs

Skipping service packs on SUSE Linux Enterprise Desktop is not supported. You need to consecutively install all service packs.

Figure 2.1: Overview of supported upgrade paths #

  

Warning: Upgrading databases

The upgrade paths described here apply only to SUSE Linux Enterprise as the operating system of a machine, not to all the applications it runs. If you have workloads such as PostgreSQL or MariaDB databases, intermediate OS upgrades may be required in order to upgrade your applications.

Before upgrading the operating system, consult the Release Notes for information about database versions. If a new major version is shipped, refer to Chapter 3, Preparing the upgrade for upgrade instructions.

SUSE supports the following upgrade and migration methods. For more information about the terminology, see Section 1.1, “Terminology”. The methods are:

Important: SUSE Manager clients

If your machine is managed by SUSE Manager, update it as described in the SUSE Manager documentation. The Client Migration procedure is described in the SUSE Manager Upgrade Guide, available at https://documentation.suse.com/suma/.

Upgrading the system is only supported from the most recent patch level. Make sure the latest system updates are installed by either running zypper patch or by starting the YaST module Online-Update.

Note: New 4096-bit signing key for SUSE Linux Enterprise 15

Mid 2023, the SUSE Linux Enterprise 15 product family switched over from a RSA 2048-bit signing key to a new RSA 4096-bit key. This change covers RPM packages, package repositories and ISO signatures. Old repositories that are not updated anymore and RPMs released up to the switch-over date, will still stay signed with the old 2048 bit key.

If you update your system, the new key is automatically imported into the RPM keyring from the suse-build-key package on SLE 15 SP 4 and SP5 as well as the LTSS versions of SLE 15 SP1, SP2, and SP3.

If the key was not imported yet, you can manually import it with:

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-3fa1d6ce-63c9481c.asc

If you are running an older version of SLE or did not import the new key, you will be asked to trust it during the upgrade. Please make sure the fingerprint matches:

pub   rsa4096/0xF74F09BC3FA1D6CE 2023-01-19 [SC] [expires: 2027-01-18]
Key fingerprint = 7F00 9157 B127 B994 D5CF  BE76 F74F 09BC 3FA1 D6CE
uid           SUSE Package Signing Key <build@suse.de>

Additionally, a reserve 4096-bit RSA key for disaster recovery purposes was imported:

pub   rsa4096/0xA1BFC02BD588DC46 2023-01-19 [SC] [expires: 2033-01-16]
Key fingerprint = B56E 5601 41D8 F654 2DFF  3BF9 A1BF C02B D588 DC46
uid           SUSE Package Signing Key (reserve key) <build@suse.de>

This key can be manually imported using:

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-d588dc46-63c939db.asc

Both keys can also be found on the installation media and the SUSE website at https://www.suse.com/support/security/keys/.

Find a list of all changes, new features, and known issues in the release notes. You can also find the release notes on the installation media in the docu directory.

The release notes usually only contain the changes between two subsequent releases. If you are skipping one or more Service Packs, check the release notes of the skipped Service Packs as well.

Consult the release notes to check whether the following applies:

Before upgrading, back up your data by copying the existing configuration files to a separate medium (such as tape device, removable hard disk, etc.). This primarily applies to files stored in /etc and some directories and files in /var and /opt. You may also want to write the user data in /home (the HOME directories) to a backup medium.

Back up all data as root. Only root has sufficient permissions for all local files.

If you have selected Update an Existing System as the installation mode in YaST, you can choose to do a (system) backup at a later point in time. You can choose to include all modified files and files from the /etc/sysconfig directory. However, this is not a complete backup, as all the other important directories mentioned above are missing. Find the backup in the /var/adm/backup directory.

Software tends to grow from version to version. Therefore, take a look at the available partition space before updating. If you suspect you are running short of disk space, back up your data before increasing the available space by resizing partitions, for example. There is no general rule regarding how much space each partition should have. Space requirements depend on your particular partitioning profile and the software selected.

Note: Automatic check for enough space in YaST

During the update procedure, YaST will check how much free disk space is available and display a warning to the user if the installation may exceed the available amount. In that case, performing the update may lead to an unusable system! Only if you know exactly what you are doing (by testing beforehand), you can skip the warning and continue the update.

Filesystem     Size  Used Avail Use% Mounted on
     /dev/sda3       74G   22G   53G  29% /
     tmpfs          506M     0  506M   0% /dev/shm
     /dev/sda5      116G  5.8G  111G   5% /home
     /dev/sda1       39G  1.6G   37G   4% /windows/C
     /dev/sda2      4.6G  2.6G  2.1G  57% /windows/D

You can save a list of installed packages; for example, when doing a fresh install of a new major SLE release or reverting to the old version.

Note

Be aware that not all installed packages or used repositories are available in newer releases of SUSE Linux Enterprise. Some may have been renamed and others replaced. It is also possible that some packages are still available for legacy purposes while another package is used by default. Therefore, some manual editing of the files might be necessary. This can be done with any text editor.

If you upgrade a SUSE Linux Enterprise Desktop system with Long Term Service Pack Support (LTSS) to a version that is still under general support, the upgrade will fail with the error No migration available. This happens because zypper migration tries to migrate all repositories, but there is no LTSS repository for the new version yet.

To fix this issue, disable the LTSS extension before the upgrade.

As a security measure, MD5-based certificates are no longer supported in Java. If you have certificates created as MD5, re-create your certificates with the following steps:

If your machine serves as a VM Host Server for KVM or Xen, make sure to properly shut down all running VM Guests prior to the update. Otherwise you may not be able to access the guests after the update.

If the machine you want to upgrade is registered as a client against an SMT server, take care to do the following:

Check if the version of the clientSetup4SMT.sh script on your host is up to date. clientSetup4SMT.sh from older versions of SMT cannot manage SMT 12 clients. If you apply software patches regularly on your SMT server, you can always find the latest version of clientSetup4SMT.sh at <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh.

In case upgrading your machine to a higher version of SUSE Linux Enterprise Desktop fails, deregister the machine from the SMT server as described in Procedure 3.1. Afterward, restart the upgrade process.

On systems that have been installed with SUSE Linux Enterprise Desktop 12 or older, the default kernel command line in /etc/default/grub may contain a resume parameter using a device node name such as /dev/sda1 to refer to the hibernation ('suspend-to-disk') device. As device node names are not persistent and may change between reboots, it is strongly recommended to fix this, otherwise the upgraded system may hang on reboot.

If the system does not use hibernation, you can simply remove the resume parameter and update the boot configuration.

Before upgrading your system, read Chapter 3, Preparing the upgrade first.

To upgrade your system, boot from an installation source, as you would do for a fresh installation. However, when the boot screen appears, you need to select Upgrade (instead of Installation). The upgrade can be started from:

The procedure below describes booting from a DVD, but you can also use another local installation medium like an ISO image on a USB mass storage device. The medium and boot method to select depends on the system architecture and on whether the machine has a traditional BIOS or UEFI.

To start an upgrade from a network installation source, make sure that the following requirements are met:

Before you upgrade your system, read Chapter 3, Preparing the upgrade first. To perform an automated migration, proceed as follows:

Note: SUSE Customer Center and Internet connection

If the system you want to upgrade is registered with the SUSE Customer Center, make sure to have an Internet connection during the following procedure.

1. After you have booted (either from an installation medium or the network), select the Upgrade entry on the boot screen.

   

   Warning: Wrong choice may lead to data loss

   Make sure you select Upgrade at this point. If you select Installation by mistake, your data partition will be overwritten with a fresh installation.

   YaST starts the installation system.

2. On the Welcome screen, choose Language and Keyboard. Proceed with Next.

   YaST checks your partitions for already installed SUSE Linux Enterprise systems.

3. On the Select for Upgrade screen, select the partition to upgrade and click Next.

4. YaST mounts the selected partition and displays the license agreement for the upgraded product. To continue, accept the license.

5. On the Previously Used Repositories screen, adjust the status of the repositories. By default all repositories are removed. If you have not added any custom repositories, do not change the settings. The packages for the upgrade will be installed from DVD, and you can optionally enable the default online repositories in the next step.

   If you have custom repositories, you have two choices:

   • Leave the repository in state Removed. Software that was installed from this repository will be removed during the upgrade. Use this method if no version of the repository that matches the new release is available.

   • Update and enable the repository if it matches the new release. Change its URL by clicking the repository in the list, and then click Change. Enable the repository by checking Toggle Status until it is set to Enable.

   Do not keep repositories from the previous release, as the system may be unstable or not work at all. Then proceed by clicking Next.

6. The next step depends on whether the upgraded system is registered with the SUSE Customer Center or not.

   1. If the system is not registered with the SUSE Customer Center, YaST displays a pop-up message suggesting using a second installation medium, the SLE-15-SP5-Full-ARCH-GM-media1.iso image.

      If you do not have that medium, the system cannot be upgraded without registration.

   2. If the system is registered with the SUSE Customer Center, YaST will show possible migration targets and a summary.

      Select one migration target from the list and proceed with Next.

7. In the next dialog you can optionally add an additional installation medium. If you have additional installation media, activate the I would like to install an additional Add On Product option and specify the media type.

8. Review the Installation Settings for the upgrade.

9. If all settings are according to your wishes, start the installation and removal procedure by clicking Update.

   

   Tip: Upgrade failure on SMT clients

   If the machine to upgrade is an SMT client, and the upgrade fails, see Procedure 3.1, “Deregistering a SUSE Linux Enterprise client from an SMT server” and restart the upgrade procedure afterward.

10. After the upgrade process has finished successfully, perform the post-upgrade steps described in Chapter 6, Finishing the upgrade.

SUSE Manager is a server solution for providing updates, patches, and security fixes for SUSE Linux Enterprise clients. It comes with a set of tools and a Web-based user interface for management tasks. See https://www.suse.com/products/suse-manager/ for more information about SUSE Manager.

You can perform a system upgrade using SUSE Manager. The AutoYaST technology allows upgrades from one major version to the next.

If your machine is managed by SUSE Manager, update it as described in the SUSE Manager documentation. The Client Migration procedure is described in the SUSE Manager Upgrade Guide, available at https://documentation.suse.com/suma/.

When performing a service pack upgrade, it is necessary to change the configuration on the registration server to provide access to the new repositories. If the upgrade process is interrupted or reverted (via restoring from a backup or snapshot), the information on the registration server is inconsistent with the status of the system. This may lead to you being prevented from accessing update repositories or to wrong repositories being used on the client.

When a rollback is done via Snapper, the system notifies the registration server to ensure access to the correct repositories is set up during the boot process. If the system was restored with another method, or the communication with the registration server fails, trigger the rollback on the client manually. An example for manually triggering a rollback can be that the server was not accessible because of network issues. To do a rollback, execute:

> sudo snapper rollback

We suggest always checking that the correct repositories are set up on the system, especially after refreshing the service using:

> sudo zypper ref -s

This functionality is available in the rollback-helper package.

If the system was not registered before running the upgrade you can register your system at any time using the Product Registration module in YaST.

Registering your systems has these advantages:

SUSE releases new service packs for the SUSE Linux Enterprise family at regular intervals. To make it easy for customers to migrate to a new service pack and minimize downtime, SUSE supports migrating online while the system is running.

Starting with SLE 12, YaST Wagon has been replaced by YaST migration (GUI) and Zypper migration (command line). This has the following advantages:

Warning: Online migration not supported for major releases

The online migration is only supported for migrating between service packs. Online migration is not supported for upgrading to new major releases. For details, see Chapter 2, Upgrade paths and methods.

Use the offline migration to upgrade to a new major release. For details, see Chapter 4, Upgrading offline.

Important: Upgrading SUSE Manager clients

If the system to upgrade is a SUSE Manager client, it cannot be upgraded by YaST online migration or zypper migration. Use the Client Migration procedure instead. It is described in the SUSE Manager Upgrade Guide.

A service pack migration can be executed by either YaST, zypper, or AutoYaST.

Before you can start a service pack migration, your system must be registered at the SUSE Customer Center or a local RMT server. SUSE Manager can also be used.

Regardless of the method, a service pack migration consists of the following steps:

The list of migration targets depends on the products you have installed and registered. If you have an extension installed for which the new SP is not yet available, it could be that no migration target is offered to you.

The list of migration targets available for your host will always be retrieved from the SUSE Customer Center and depend on products or extensions installed.

A service pack migration can only be canceled at specific stages during the migration process:

To perform a service pack migration with YaST, use the Online Migration tool. By default, YaST does not install any packages from a third-party repository. If a package was installed from a third-party repository, YaST prevents packages from being replaced with the same package coming from SUSE.

Note: Reduce installation size

When performing the Service Pack migration, YaST will install all recommended packages. Especially in the case of custom minimal installations, this may increase the installation size of the system significantly.

To change this default behavior and allow only required packages, adjust the solver.onlyRequires option in /etc/zypp/zypp.conf.

solver.onlyRequires = true

Additionally, edit the file /etc/zypp/zypper.conf and change the installRecommends option.

installRecommends=false

This changes the behavior of all package operations, such as the installation of patches or new packages. To change the behavior of Zypper for a single invocation, use the parameter --no-recommends.

To start the service pack migration, do the following:

To perform a service pack migration with Zypper, use the command line tool zypper migration from the package zypper-migration-plugin.

Note: Reduce installation size

When performing the Service Pack migration, YaST will install all recommended packages. Especially in the case of custom minimal installations, this may increase the installation size of the system significantly.

To change this default behavior and allow only required packages, adjust the solver.onlyRequires option in /etc/zypp/zypp.conf.

solver.onlyRequires = true

Additionally, edit the file /etc/zypp/zypper.conf and change the installRecommends option.

installRecommends=false

This changes the behavior of all package operations, such as the installation of patches or new packages. To change the behavior of Zypper for a single invocation, use the parameter --no-recommends.

To start the service pack migration, do the following:

If your system is not registered because you do not have access to the Internet or a registration server, migrating to a new service pack is not possible with YaST Migration or zypper migration. In this case you can still migrate to a new service pack with plain Zypper and some manual interactions.

Important: For unregistered systems only

This migration path to a new service pack is only supported for unregistered systems that do not have access to the Internet or a registration server. This may, for example, be the case for machines in a specially protected network. If you have a registered system, use YaST or Zypper migration.

Important: Installation sources

This migration path requires that the system you are going to migrate has access to the installation sources. For example, this can be done by setting up an RMT server or an SLP server.

It is also required that the system has access to an up-to-date update repository for the installed product version.

If a service pack does not work for you, SUSE Linux Enterprise supports reverting the system to the state before the service pack migration was started. Prerequisite is a Btrfs root partition with snapshots enabled (this has been the default since SLES 12). See Book “Administration Guide”, Chapter 10 “System recovery and snapshot management with Snapper” for details.

Now you have successfully reverted the system to the state that was captured immediately before the service pack migration was started.

SUSE Manager is a server solution for providing updates, patches, and security fixes for SUSE Linux Enterprise clients. It comes with a set of tools and a Web-based user interface for management tasks. See https://www.suse.com/products/suse-manager/ for more information about SUSE Manager.

SP Migration allows migrating from one Service Pack (SP) to another within one major version (for example, from SLES 15 GA to SLES 15 SP5).

If your machine is managed by SUSE Manager, update it as described in the SUSE Manager documentation. The Client Migration procedure is described in the SUSE Manager Upgrade Guide, available at https://documentation.suse.com/suma/.

Use zypper packages to check for orphaned and unneeded packages.

Orphaned Packages are no longer available in any of the configured package repositories. They can no longer get updated and become unsupported.

For a list of orphaned packages, run:

> zypper packages --orphaned

Unneeded packages are dependencies of packages that have been installed either explicitly by the user or implicitly as part a pattern or product, and that have been removed in the meantime. They are usually no longer needed and should be removed, too.

For a list of unneeded packages, run:

> zypper packages --unneeded

Tip

To avoid unneeded packages, use zypper rm with the --clean-deps option or YaST with Options › Clean up when deleting packages enabled.

You can combine both lists into one:

> zypper packages --orphaned --unneeded

Use these lists to determine which packages are still needed and which can be safely removed.

Warning: Do not remove packages you need

If packages get renamed, or removed from a pattern or product, zypper may no longer consider them explicitly installed and mark them as unneeded, even though they are still crucial for your installation.

Carefully review the list of packages you are removing.

To remove all orphaned and unneeded packages with a single command, run:

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5)

Exclude a single package or pattern from being uninstalled:

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5 | grep -v PACKAGE_TO_EXCLUDE)

Exclude multiple packages defined in a text file, separated by a newline:

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5 | grep -v -f /PACKAGES/TO/KEEP.txt)

Check for any *.rpmnew and *.rpmsave files. When an upgrade includes changes to a default configuration file that has been altered after package installation, instead of overwriting the file, one of these file types is created. While *.rpmnew contains the new default configuration and leaves your altered file untouched, *.rpmsave is a copy of your altered configuration that has been replaced by the new default file.

If you find any of these files, examine their content and merge desirable changes. You do not need to search the whole file system, only the /etc directory. Use the following command:

> find /etc/ -name "*.rpmnew" -o -name "*.rpmsave"

SUSE Linux Enterprise Desktop 15 uses Python 3.6 by default. Python 3.9 was added in SLED 15 SP3 as a more recent alternative. This version is no longer supported as of SLED 15 SP4. Instead, recent Python versions with important updates and security fixes are available through the Python 3 module.

If you installed Python 3.9 under SUSE Linux Enterprise Desktop 15 SP3, enable the Python 3 module with:

> sudo SUSEConnect -p sle-module-python3/15.5/x86_64.

Alternatively, you can return to the default Python version by removing 3.9 with zypper remove -u python39.

SUSE Linux Enterprise Desktop supports the “on-disk format” (v5) of the XFS file system. The main advantages of this format are automatic checksums of all XFS metadata, file type support, and support for a larger number of access control lists for a file.

Note that this format is not supported by SUSE Linux Enterprise kernels older than version 3.12, by xfsprogs older than version 3.2.0, and GRUB 2 versions released before SUSE Linux Enterprise 12.

Important: V4 is deprecated

XFS is deprecating file systems with the V4 format. This file system format was created by the command:

> sudo mkfs.xfs -m crc=0 DEVICE

The format was used in SLE 11 and older releases, and it currently creates a warning message by dmesg:

Deprecated V4 format (crc=0) will not be supported after September 2030

If you see the message above in the output of the dmesg command, it is recommended that you update your file system to the V5 format:

1. Back up your data to another device.

2. Create the file system on the device.

   > sudo mkfs.xfs -m crc=1 DEVICE

3. Restore the data from the backup on the updated device.

Upstream developers are primarily concerned with advancing the software they develop. Often they combine fixing bugs with introducing new features which have not yet received extensive testing and which may introduce new bugs.

For distribution developers, it is important to distinguish between:

Usually, distribution developers do not follow all upstream changes when a package has become part of a released distribution. Usually they stick instead with the upstream version that they initially released and create patches based on upstream changes to fix bugs. This practice is known as backporting.

Distribution developers generally will only introduce a newer version of software in two cases:

SUSE uses backports extensively as we strike a good balance between several concerns for enterprise software. The most important of them are:

It is a general policy rule that no new upstream versions of a package are introduced into our enterprise products. This rule is not an absolute rule however. For certain types of packages, in particular anti-virus software, security concerns weigh heavier than the conservative approach that is preferable from the perspective of quality assurance. For packages in that class, occasionally newer versions are introduced into a released version of an enterprise product line.

Sometimes also for other types of packages the choice is made to introduce a new version rather than a backport. This is done when producing a backport is not economically feasible or when there is a very relevant technical reason to introduce the newer version.

Because of the practice of backporting, one cannot simply compare version numbers to determine whether a SUSE package contains a fix for a particular issue or has had a particular feature added to it. With backporting, the upstream part of a SUSE package's version number merely indicates what upstream version the SUSE package is based on. It may contain bug fixes and features that are not in the corresponding upstream release, but that have been backported into the SUSE package.

One particular area where this limited value of version numbers when backporting is involved can cause problems is with security scanning tools. Some security vulnerability scanning tools (or particular tests in such tools) operate solely on version information. These tools and tests are therefore prone to generating “false positives” (when a piece of software is incorrectly identified as vulnerable) when backports are involved. When evaluating reports from security scanning tools, always check whether an entry is based on a version number or on an actual vulnerability test.

Information about backported bug fixes and features is stored in several locations: