We are updating our release model for BIND, starting in 2018.
- We already shortened our release cycle from 9.10 and 9.11, each of which took >24 months, with 9.12, which we will bring out in less than 18 months. Going forward, we want to produce a new branch every year.
- We intend to make early (.0 and .1) releases of new branches much more stable than previously, by minimizing changes from the prior stable branch.
- We will provide frequent new development drops for users who want to try new features
- We are committed to continuing to provide an extended support version (ESV) for users who are most concerned about stability and want to minimize branch changes.
- Finally, we need to minimize the total number of supported versions at a given time while providing both fresh new and old stable branch options.
What is changing?1) New development releases
The biggest change will be the addition of development releases. Starting as soon as we release 9.12.0, we plan to create frequent releases of the Master branch, naming them 9.13.0, 9.13.1, etc. Thus, we will start issuing new versions as soon as we start development on the branch, and will not wait for a year or more of development to pass, as we have traditionally done. When we near the end of 2018 and the development of the BIND 9.13 version has had a handful of releases, we will renumber it and release it as BIND 9.14. This way, the new BIND version should be much more stable and well-tested than if there was a year’s worth of new changes since the prior release.
2) Annual Stable versions
We plan to bring out new branches approximately every 12 months. Releases that are not designated as ESV will be supported for 12 months and then replaced with a new branch. Historically, our .0 and .1 releases were not stable enough for large scale production use. We believe that by issuing frequent development releases off of our master branch and then renumbering that at the end of a year’s development, we can achieve stability with the initial release on the subsequent branch. This change is in line with our recent efforts to shorten the gap between new branches, already begun with 9.12.
ESV and Subscription versions are not changing3) Extended Support Version - Supported for Four Years
The Extended Support Version (ESV) is intended for users who update infrequently, or who have a long pre-deployment integration or validation cycle. BIND 9.11 will be our next extended support version, followed by BIND 9.16. Every other Stable version after that will be designated for extended support.
We will continue to support ESV versions for 4 years from development but late in the cycle we may only update these branches if there are security vulnerabilities in them - which will minimize churn for those long-stable versions. The only real change in our ESV commitment is, we will indicate which releases will become ESV at the start of the branch, rather than waiting for several maintenance releases.
4) Subscription Edition
The Subscription Edition was created for our support customers who want to enjoy some of our newest BIND features, while running an older stable version. It is also known as our ‘Supported Preview’ edition because we selectively backport and integrate new features (including unreleased ones) into an old stable version. Because we are willing to incorporate experimental new features into the Subscription Edition, we also may later remove or change some of these features, based on subscriber feedback.
What Version Should I Use?See this updated knowledge base article on selecting a BIND version.
- Beginning in 2018, we will make minimal changes to the 9.9 and 9.10 branches in preparation for ending support in mid 2018.
- BIND 9.11 will become our next extended support version, replacing 9.9.
- We will overlap ESV and Subscription branches so that users who have an extended in-house test cycle have time to validate or integrate the new ESV before migrating.
- Branches which are not going to be extended-support versions will be short-lived.
- We will start a new master branch every year, and will begin releasing development versions on that branch immediately
Example Release Plan
The example below illustrates the contrast between the long-lived ESV releases and the 12-month stable and development releases. The 9.11 ESV will be even more long-lived than the planned 4 years from release, in order to help us transition to this new model.
What you can’t really see from this is, the new stable release will effectively just be a renumbering of the prior year’s development release. Once we make the transition, odd-numbered versions (9.13 and above) will be development versions, and even-numbered versions will be stable. We will also note which is which on our downloads page.
Sharp observers might see below that we were considering removing the “9” from the release numbers, a change we decided not to make at this time.