There has been a lot of discussions lately about changing how the CFEngine releases work, and what we want is to have something that is more systematic and predictable. There are many points that need to be considered, for instance:
How often should we release a new feature release?
- How often will people actually upgrade?
- How often would contributors like to see new releases (with their fixes in)?
How long should feature releases be supported?
How many releases can we make a year from a workload perspective?
When should the releases be?
These are some of the points that have fueled the discussions, and some of them are in direct conflict with each other, so it’s hard to find the perfect solution. What we have come up with is what we believe is the best compromise of the above considerations, and should hopefully make most people happy. The first thing we will do is to introduce the concept of Long Term Support releases (LTS for short). A good example of another company that uses LTS releases is Canonical, which releases their Ubuntu Operating System every half year, but LTS releases only every second year. What makes the difference is that the non-LTS releases have a shorter support span, whereas the LTS releases have a support period of several years. The second thing we will do is to switch to time based releases, which means that we will no longer delay a release in order to wait for features that are in development, but will release at regular intervals with the features that are available at that time. The advantage of this is that releases are predictable and users will know when the next release containing their fix will be. It is also a great way to bring features out faster, both from us and from contributors. Here are the differences between a non-LTS and an LTS release:
| Feature | non-LTS | LTS |
|---|---|---|
| Release interval | Every 6 months | Every 18 months |
| Enterprise and Community packages | Yes | Yes |
| Period of maintenance updates | 6 months | 3 years |
| Enterprise professional support | No | 3 years |
From a stability perspective, here is what can be expected from each type of release:
| Feature | non-LTS | LTS |
|---|---|---|
| Based on a stable branch1 | Yes | Yes |
| Subject to full automatic test suite | Yes | Yes |
| Subject to scale testing | No | Yes |
| Subject to manual user testing | No | Yes |
1 “Stable branch” means that it is subject to a strict policy with regards to feature integrations, code refactorings and bug fixes. Only critical bug fixes are allowed in such branches, which keeps them stable and avoids the inherent stability risk of new features. New features will only be made available in new feature releases. The feature releases are aimed to be released in June and December each year, but be aware that we cannot guarantee these release times, and we may occasionally have to delay a release (however, this will not affect the time of the next release). This implies that LTS releases will be released on a schedule that alternates between summer and winter, with 18 months in between. Maintenance releases will be released as long as the release is supported, based on need. What all this boils down to is that 3.7.0 is our first LTS release, which means that 3.8 will be a non-LTS release. Here is a figure showing the release and support schedule from 3.7 onwards:
Release schedule
Update (29 Dec 2015): Release diagram has been changed slightly to better reflect that intended target is start of June/December, not start of July/January. Our hope is that this release schedule will give the most benefit to all parties involved. Over time, we may make additional adjustments to the plan if we find that certain aspects are not working as intended, but this is the current and effective schedule. Enjoy!
