ISC's Software Support Policy and Version Numbering
  • 05 May 2022
  • 8 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

ISC's Software Support Policy and Version Numbering

  • Dark
    Light
  • PDF

The purpose of this statement is to help users determine how long a given ISC release is likely to be supported. This information is useful when deciding when to schedule a migration, or in some cases, to help determine which version to migrate to when updating.

For the most current information on the status of any particular software version, please refer to the software status listed on the downloads page.

BIND 9 (updated as of 1/2022)

Major versions

We have four types of major BIND 9 versions: Development, Stable, Extended Support (ESV), and Supported Preview (also known as "Subscription," or -S).

bindrelease1-26-22

Development versions

We release Development versions off of the current working (main) branch. These are the odd-numbered major versions, such as BIND 9.17, 9.19, etc.

We typically release minor Development releases monthly (e.g. 9.19.1, 9.19.2). Development version minor releases introduce new features and significant refactoring and may not be backward-compatible with their immediate predecessor. Development versions of BIND are suitable for those interested in experimenting with and providing feedback to ISC upon their features. There are no alpha, beta or release candidates published. This process has been replaced with development versions. It may sometimes happen that a recently-released minor version is superseded very quickly in order to address a flaw. We may not issue -P releases for Development versions with security bugs, at our discretion.

Development versions are supported for 24 months. At the end of the 24-month period, the stabilized Development version is re-labeled and re-released as the next Stable version, and we will begin a new Development branch.

Stable versions

We stabilize all the even-numbered major versions for production use – for example, BIND 9.16 and BIND 9.18. Each major branch has a series of minor releases, such as BIND 9.16.0, 9.16.1, etc.

Stable branches of BIND get minor feature updates and bug fixes for 12 - 18 months, but then are put into Extended Support mode and receive only critical fixes and eventually, only security patches. Within a Stable branch, users should be able to update from one minor version to another without worrying about a break in backward-compatibility.

Extended Support versions (ESV)

Every Stable version moves into Extended Support after a year or so of active development, for a total lifetime of four years from initial release. Organizations with a long internal validation, integration, or deployment cycle should consider beginning their validation process with a Stable version and deploying when that branch enters the Extended Support phase.

See the accompanying chart which shows when we plan to declare ESV status. For example:

  • BIND 9.11 is an Extended Support version, and will be supported until December 2021. Additionally we may issue patches for any CVEs found during Q1 of 2022.
  • BIND 9.16.19 and later is ESV, followed by BIND 9.18; every Stable version after that will be ESV.

Supported Preview (also known as "Subscription," marked -S)

Releases marked with a -S are part of ISC’s Supported Preview edition. These releases provide a deployable, supported vehicle for our support customers to receive early access to new features in development. The -S edition is created for and available to ISC paid support subscribers, and may also be offered to community developers for testing and feedback. The -S edition includes select unreleased software (new features and other changes) that ISC judges to be stable enough for production use. Features in the -S version may still be in development and may be changed or even removed by the time of the public release.

The -S edition releases are usually based on an ESV branch, and are actively maintained and patched in case of security vulnerabilities, just as our regular public releases are. The -S edition is offered under the same license terms as the open source BIND 9, but redistribution is constrained by the support agreement between ISC and the support subscriber.

The -S support plan is different from regular releases:

  1. When we put out a new maintenance release, we do a corresponding -S1 that normally includes all the bug fixes in the maintenance release, and is normally a superset of the code in the corresponding maintenance version.
  2. If we have to do a security patch (-P), we do a corresponding -S for the -S edition. For example, if we were issuing a 9.9.8-P1, and the current release of the S edition was 9.9.8-S1, the corresponding security release for the -S edition would be numbered 9.9.8-S2.
  3. We add changes (new features) to the -S edition between maintenance releases that we do not add to a maintenance release of the public edition.
  4. We do not support more than one -S edition release on any given branch.
  5. When we start producing an -S edition on a new branch, we continue to support the -S edition on the prior branch for another six months to support migration.

Minimal security updates

All supported versions of BIND 9 may occasionally receive unscheduled releases in response to a critical security bug; in that case, the changes introduced between that version and its predecessor are minimal and necessary only.

Operating System support

We have a published list of supported operating systems. These are the operating systems we can test on, or that we know to work. BIND may compile and run on other operating systems or versions but we don't guarantee it and we cannot commit to fixing issues with those operating systems or building packages for them. See the platforms.md statement in the BIND repository.

Deprecating features

We have established a process for removing named.conf options. This is a gradual and phased process intended to provide ample notice of a coming change that might break an established configuration.

Kea

We have two types of major Kea versions: Development and Stable. At any given time, we should have three options available: two Stable releases and one Development release.

Kea release plan updated April 2021

Development versions

We release Development versions off of the current working (master) branch. These are the odd-numbered minor versions (where the second digit of the release number is odd), starting from Kea 2.1.0, 2.1.1, 2.1.2 and so on, until that branch is replaced with the next odd-numbered minor version, Kea 2.3.0.

We typically issue Development branch releases monthly. These minor updates will introduce new and updated features and may not be backward-compatible with their immediate predecessor. Development versions of Kea are suitable for those interested in experimenting with and providing feedback to ISC, but are not recommended for production use. There will be no alpha/beta/release candidate versions of Development versions, and it may sometimes happen that a recently-released minor version is superseded very quickly in order to address a flaw. We may not issue patch releases for Development versions with security bugs, at our discretion.

Development versions are maintained until the next Stable version is created, at which time we begin a new Development branch (with the next odd number). We estimate Development versions will mature into Stable versions in approximately a year, but this is a prediction, not a promise.

Stable versions

All the even-numbered minor versions (where the second digit of the version number is even) are for production use – for example, Kea 1.8 and Kea 2.0 are Stable versions. Each of these branches will have a series of maintenance releases, such as Kea 2.0.1, 2.0.2, etc. Maintenance releases on a Stable version include bug fixes only, to maximize stability. There is no fixed schedule for issuing maintenance releases and we will release one only if there are significant issues to repair.

Stable versions of Kea are fully supported for at least six months after the next Stable version is released. This means you should have ample time to migrate to a new Stable version before the older one is EOL. We do not yet have "Extended Support" versions of Kea; we still have a very high rate of new feature development and are not yet ready for a long-lived Stable branch. We expect to be able to update the Kea DHCP packages the same day we post the tarballs.

Operating System support

We have a published list of supported operating systems. These are the operating systems we can test on, or that we know to work. Kea may compile and run on other operating systems or versions but we don't guarantee it and we cannot commit to fixing issues with those operating systems or building packages for them. See the platforms.md statement in the Kea repository.

Stork

Stork is considered an experimental or best effort project. All releases should be regarded as Development releases. It is under active development and we cannot guarantee that there will not be backwards-incompatible changes at this time.

Other general policy guidelines

Standard support terms do not apply to Development releases, Stork, or the BIND Supported Preview edition. Development releases are typically shorter-lived releases and are not recommended for production deployment.

ISC DHCP

We maintain two branches of ISC DHCP:

  • DHCP 4.1-ESV was originally scheduled to go to EOL in December 2015, but we have extended this indefinitely to maintain a smaller-footprint edition.
  • DHCP 4.4 is the current ESV version. The client and relay components are EOL with version 4.4.3. At this point, no EOL is established for the DHCP server component.
  • All other versions of ISC DHCP, including 4.2.x and 4.3.x, are EOL.
  • ISC will cease support for the ISC DHCP Client and Relay by the end of Q2, 2022. We will continue maintaining the Server and common code only, beyond this point.

We are nearing the end of maintenance for ISC DHCP (relative to its 20-year lifespan). The exact timeframe for EOL will depend on the maturity of Kea and other available alternatives.