How are the versions of minor releases determined in Red Hat Enterprise Linux?

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 9
  • Red Hat Enterprise Linux 8
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 5

Issue

  • How are the versions of minor releases determined in Red Hat Enterprise Linux?
  • Does it depend upon kernel version?

Resolution

Red Hat Enterprise Linux is a maintained collection of different components, which are drawn from the wider open source software community. At the time that our product is released, Red Hat has a particular version of each of the software components, selected for features and stability. During the life cycle of our product, Red Hat backport any relevant bug fixes and security enhancements created by the upstream maintainers to the packages that we maintain, as well as contributing any fixes that Red Hat does.

It's not necessary that the version numbering schemes are the same as the upstream projects, Red Hat has our own version numbering scheme for the packages that we create based on these backported changes. Red Hat does not change the version of any software components based on the release of a new version by an upstream project. Click here to check the Errata Page

For more details, Article 2074 may be useful. This is how backporting is done on Red Hat Enterprise Linux packages and versions are kept stable. There are some policies of Red Hat on delivering the packages and determining the versions. Some of those are as follows.

[1] Red Hat ships a particular package for long time basis.

[2] The package and its version is taken from upstream and it's delivered for long time basis. However, Red Hat still have to include the bug fixes and latest updates to the package. For this reason, Red Hat backports the new changes to our package rather than changing our version numbers to the highest version.

[3] Sometimes, customers are certifying their applications for the version number which we provide. If Red Hat continuously change the version number to the highest in short span of time, their certification will get expired.

When GA versions of Red Hat Enterprise Linux is to be released, the packages are rebased and GA is released after testing the stability and compatibility. For throughout lifecycle of that GA, the rebasing is not done, (i.e. the base package major versions won't change), but the security fixes and bug-fixes are released in the form of asynchronous erratas. The base package major version is maintained same through out the lifecycle of the GA version of Red Hat Enterprise Linux for stability and compatibility, but the minor version/releases of the packages changes as per the errata updates.

Every package has a major version, minor version and a release as follows.

<name>-<major_version>-<minorversion>-<release>.<architecture>.rpm

So whenever in upstream, if any security vulnerability is identified, at that time, the patch is backported to the Red Hat package which doesn't change the major version but the minor versions and releases changes. All known issues were addressed via backporting, there may not be a plan to change the base number of ssh in Red Hat Enterprise Linux 5. The major version release number changes when the complete re-basing of the package is done. E.g. Firefox. Please refer to the following link for more detailed information on the backporting.

During the entire Life Cycle, Red Hat makes commercially reasonable efforts to maintain binary compatibility for the core
runtime environment across all Service Packs and asynchronous errata advisories. Red Hat may elect to make exceptions to
the compatibility goal for critical impact security or other significant issues. Furthermore, major releases of Red Hat
Enterprise Linux contain a limited set of backward-compatible libraries from the previous major releases to allow for the
easy migration of applications. In order to minimize the amount of change and to maintain the binary compatibility, fixes
generally are back-ported to the respective version of RHEL. Exceptions may apply for controlled re-bases, packages that
are provided primarily to satisfy dependencies, or Desktop applications.

Red Hat Product Life-cycle

If one installs a particular version of Red Hat Enterprise Linux, the minor version depends upon the update level of all packages available into the server. This doesn't depend upon simply kernel version or redhat-release package. To understand this concept, refer to the following scenarios.

[1] If one installs a server with Red Hat Enterprise Linux 6.0 ISO, at that time, the update level of packages will be at RHEL6.0 only but if he/she update the packages kernel and redhat-release by following command, it will give me somewhat different results.

    # yum update kernel redhat-release*

If he/she checks the version of the server after execution of the above command, it will show me that the server is at the latest RHEL6 version (which is RHEL6.10 at the moment). This is only a label, kernel is updated but all packages are from Red Hat Enterprise Linux 6.0.

[2] If one installed a server with same RHEL6.0, and he executes the following command after putting skiplist packages entry of kernel and redhat-release in /etc/yum.conf, the results will be bit different.

    # yum update

This command will update all the packages except kernel and redhat-release* and the system will show that its Red Hat Enterprise Linux 6.0 as redhat-release* package is not updated.

From above both the scenarios, It can be understood that the minor release version depends upon the complete package update level. And once the RHEL 6 system is registered to RHN's main base channel, it simply becomes RHEL 6 system. And if there are any particular requirements to be on a specific minor release, there is an option of Extended Update Support (EUS) Subscription, this will ensure that you are on a specific minor release as the channels for EUS are different.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments