• All Downloads
• Basic vs. Full Edition
• Supported Versions
• Support Policy/Lifecycle

Visit Us On

Cucumber Linux Lifecycle

Updated April 22, 2017

Stages of the Lifecycle

Each release of Cucumber Linux has a lifecycle consisting of four stages. These stages are explained in detail below.

Development

The first stage in Cucumber’s lifecycle is the development stage. This is where all the interesting development happens. The development stage is the only stage at which version numbers of the core packages are permitted to change. The core packages include the packages that are absolutely essential to the system’s functionality (such as the Linux Kernel, Binutils, Coreutils, GCC, etc) and any packages where upgrading to a new version has a high potential of breaking existing packages, configurations and other stuff (such as Apache, OpenSSL, PHP, Python, Perl, etc). Note that this only applies to changes in the major/minor version number, not the release number.

Additionally, the development stage is the only stage where packages can be added to and removed from the base and general package groups; the development stage is also the only stage where packages can be removed from (but not added to) the extra package groups. New packages can be added to the extra groups (and only the extra groups) post release, provided they do not in any way impede the functionality of any packages in the base or general groups.

There is (generally) no set time frame for the development stage. New versions of Cucumber Linux are released when they are ready, not at a fixed interval like many other distributions.

Full Support

After a version of Cucumber Linux is released, it is moved into full support stage. During the full support stage, security updates and important bug fixes are provided for all of the packages in the base and general package groups. These patches only affect the release number of the core packages, not the major/minor version numbers (see the development section for a definition of core packages). Naturally, this requires that all of the core packages are supported upstream. For this reason a given release of Cucumber Linux can only be fully supported until upstream support for any one of the core package versions ends. Once this happens, the release is moved from the full support stage to the selective support stage.

While there is no fixed time frame for this stage, it is almost always known at release time how long the a given Cucumber release will receive full support (due to the fact that we usually know when upstream support is going to end for most of the core packages). Usually, full support is given for about a year. We recognize that this is a relatively short period of time (especially when compared to other “stable” distributions). To help deal with this problem, we created the selective support stage and the minor release policy (which are detailed below).

Selective Support

After upstream support ends for one of the core packages, it is no longer possible to offer full support for the entire system. However, it is still possible to provide support for the rest of the packages that are still supported upstream. This is where the selective support stage comes in. During selective support, security patches and critical bug fixes are provided for the packages that are still supported upstream.

It is important to note that a version of Cucumber Linux may not be completely secure when it is receiving selective support. You will get some security patches, but not all of them. The philosophy here is that some support is better than none. Additionally, this is similar to the policy that the Slackware Linux distribution employs, and it’s worked pretty well there for 25 years now. Nonetheless, users of a version of Cucumber Linux that is on selective support are strongly encouraged to update to a version that is still receiving full support.

Again, there is no set time frame for the selective support stage. If there is a new minor release of Cucumber Linux available for the current major version, selective support will usually last for a few months after the end of full support. If the current minor release is the last minor release of its corresponding major version, then selective support will be provided for a much longer period of time.

End of Life

After selective support ends for a release of Cucumber Linux, that release moves the end of life stage. Releases that are at the end of life stage receive no updates whatsoever for any reason. This includes updates for a package that may still be supported upstream. Keep in mind that while official packages won’t be built anymore, the buildscripts for all of the packages in Cucumber Linux are available in the source directory, so it is possible to build updated packages yourself. If you do this though, you have voided your nonexistent warranty (see the license for more details) and are you are now solely responsible for your system’s security.

Users of end of life releases are strongly encouraged to upgrade to a supported release as soon as possible.

Minor Releases vs Major Releases

In order to deal with the brevity of the full support stage, each major release of Cucumber Linux (i.e. 1.x) will have several minor releases (i.e. 1.0, 1.1, 1.2, etc). With each minor release, several core packages whose upstream support will be ending soon will be updated to newer versions, which will be supported further into the future. This effectively allows a major release (1.x) to be supported for several years by releasing several minor versions, at least one of which will always have full support (until the whole 1.x branch goes to end of life, which usually isn’t until several years after its initial release).

Only packages that absolutely have to be updated for continued upstream support are updated between minor versions; there is no updating of packages just for the sake of having new, shiny software. These minor updates aim to be as undisruptive to the system operation as possible. It is often possible to update to a new minor release with next to no effort from the system administrator.

When configuring your system, you can actually configure Pickle to automatically use the latest minor version. To do this use the rolling release mirror, which is the mirror with the “.x” for the minor version number (i.e. choose http://mirror.example.com/cucumber-1.x/cucumber-x86_64 instead of http://mirror.example.com/cucumber-1.0/cucumber-x86_64). However if you wish to stabilize your system on a specific minor version and update minor versions manually, this can also be done by using a release mirror, which is a mirror without the “.x” for the minor version number.