cPanel & WHM’s tiered update system has long allowed us to release new versions and features in stages. Each tier provides us access to a different type of feedback from a specific segment of our user-base.

The EDGE tier is a non-production tier that allows us to incorporate feedback from our users in an earlier and more actionable stage of our development cycle, and gives third party developers a chance to test their applications against new versions of the software. The CURRENT, RELEASE, and STABLE tiers are production-ready tiers, and help us deliver a consistent experience to our users. Additionally, coupled with a deferred rollout they allow us to triage any bugs that aren’t caught in our pre-release testing. The LTS tier allows users to stay on a single major release until they choose to upgrade to the next major version, while still receiving bug fixes and security updates.

Starting in 2017: One LTS Release per Year

As of January 2017 we will only be adding a single new version of cPanel & WHM to the LTS tier. Under the new model the first release of a new calendar year will enter the LTS tier at the same time as it enters the STABLE tier. The rest of the release tiers will update regularly with the new versions of cPanel & WHM as we traverse through our regular development cycle. There will be some overlap of support for the existing version and the new version in the LTS tier, but the length of that overlap has not yet been defined. 

To illustrate, the only new version of cPanel & WHM to enter the LTS tier in 2017 will be version 62 and it will do so in the first quarter of the year. If we reach our goal of 4 version releases in 2017, the next version to enter the LTS tier would be version 70 in the first quarter of 2018. Version 62 and 70 would coexist in the LTS tier until support for version 62 ends, at which point version 70 would be the only version in the LTS tier for the remainder of 2017.

If you draw it out, next year would look something like this[1]:

Why the change?

First and foremost: we’re matching our release cycle to our customer’s use patterns. In discussions with our clients we have identified that the overwhelming majority of the companies making use of the LTS tier follow the same pattern: they stay on one release version of our software until it is nearing End of Life, and then upgrade to the newest stable version. Since our releases have a one year life-span, it means those servers are upgrading to a new release version on average once a year.

Second, we reduce our development overhead. If we use the second quarter of 2016 as an example, cPanel’s developers were required to track and maintain (meaning providing security and bug fixes) for four versions of cPanel & WHM (11.50, 11.52, 54, 56) while working to develop a fifth (version 58). During that time only around 4% of our licenses were running a supported version of cPanel & WHM on an LTS tier, and 95% were on one of the release tiers (CURRENT, RELEASE, STABLE).

By reducing our supported LTS versions to only one a year, we only need to track and maintain two versions of cPanel & WHM while developing a third. That will free up signifiant time for our developers, our infrastructure, and our support team.

What this means for our users

For our typical users, this change will mean very little. People using the LTS tier will continue to do exactly as they have, and anyone using other tiers will continue to enjoy the continuous development to which they have become accustomed.

The one thing that might feel a little different for our long-time users is our security releases. We will still only release security updates for supported versions of cPanel & WHM, which means that only versions in the LTS, CURRENT, RELEASE, or STABLE tiers receive security updates. As soon as a version is replaced in the release tiers by its predecessor, it will reach End of Life.

How do you feel about this idea? I’d love to hear from you! Leave a comment below, find me on twitter, or send me an email.

[1]These dates are used as examples to illustrate what next year might look like for us and should not be considered finalized dates.