Red Hat Enterprise Linux: Release Speed

Background

Recently, I came across an article entitled: 5 Reasons Not to Use CentOS. While I actually disagree with all five points from a technical debate standpoint, I think this article is really the result of a few pain points that some developers express when talking about enterprise editions of Linux.

Working as a technology evangelist at Red Hat, I attend a multitude of conferences and community events. When speaking with developers, a common concern is that the versions of packages in Red Hat Enterprise Linux (RHEL) and all downstream rebuilds are too old for how fast they need to move to provide value to their business. I believe that in some cases, this is a completely valid concern.

There is the age old struggle between innovation and stability. There are several factors involved in the stability of an Enterprise Linux distribution including release cycle, support lifecycle, library compatibility (API) and binary compatibility (ABI). Obviously, there are trade-offs between stability and having the latest features, some of which I will explore in this article.

What is Stability?

There is much more to stability than how many bugs are tracked and resolved over a particular period in time. Both RHEL5 and RHEL6 will be supported for 10 years respectively. The total lifecyle of support for the platform is important because, the longer it’s supported, the more value developers and users can derive from their application software. Their work can continue to provide business value without being derailed by migration and testing on a newer version of the platform.

To provide an example which both developers and users alike can connect with, take Gnome 2. There have been quite a number of users frustrated with Gnome 3; many just don’t want to use it. This has led to several forks including Cinnamon and MATE. These forks fragment the community, but worse are expensive from a resource perspective. With RHEL6, which is based on Gnome 2, the user is supported until 2020. This means those, that do not want to switch to Gnome 3, have plenty of time. In the case of Gnome 2 vs. Gnome 3, the user is free to find another acceptable desktop or perhaps wait for the next major version to mature, but imagine your business had to support several versions of a major piece of accounting software; how expensive would that be?

What is the Release Cycle?

To provide a little background, RHEL has a target release of every three years, but as with any large software project, release dates often slip. RHEL5 was released GA March 15, 2007 while RHEL6 was released November 10, 2010. This was just shy of four years between RHEL5 and RHEL6.

First and foremost, I have no special insight or authority when it comes to the RHEL product release cycle, but during this time there was tremendous change in the Red Hat Linux world. KVM became the hypervisor of choice and it is obvious that plenty of technical resources were dedicated to KVM and Red Hat Enterprise Virtualization. Making these tremendous changes while at the same time providing stability, takes time.

During the time it took to release RHEL6, the version of the packages in RHEL5 began to show their age. As time went on, the desire for newer packages in RHEL5 seemed to become more pronounced. The early adopters had moved on to newer versions of languages, libraries, and frameworks. The early understanders (which I consider myself) even questioned how long the next release was taking.

When RHEL6 was released, the contrapositive appeared true. The desire for newer packages subsided and developers went back to work on creating applications, knowing that the work they created would provide business value for up to ten years. So, how to balance innovation (features) with stability?

Resolution

Well, I suspect the resolution to the challenge of older packages is a combination of things. First, I think the problem manifests it’s self most evidently in the versions of languages, frameworks, and libraries in loose order of priority, so I will focus my examples there.

I believe that tighter adherence to the 3 year release cycle combined with Software Collections and the new Developer Subscription could help to alleviate the challenge of older versions of Ruby, Python, PHP, Perl, Java, C and C++.

In addition to tighter adherence to the targeted release cycle, as Ruby, Python, PHP, and even MySQL mature, release of major versions of these software packages may slow down. This may be offset by the challenge of newer languages and frameworks such as Node.js, but this is again where Software Collections may play a major role.

Finally, there is a range of use cases especially across vertical markets. In some markets such as Technology and Media, things will always change quickly, perhaps too quickly for an enterprise distribution of Linux. In my experience, this is the exception and not the rule. In verticals such as Banking, Energy, Manufacturing, Government, Transportation, etc, platform stability combined with some developer discipline on package versions can combine to create applications which provide great business value over a long ROI cycle. This allows developers to focus on creating new application instead of maintaining existing applications.

 

Better explanation