Clarification to ISC's Software Release Numbering Policy

[Sue Graves]

Software release numbering policy for BIND and DHCP

ISC is making a minor change to the way we number BIND releases,
as a way to simplify the upgrade process for our users.

The current BIND and DHCP version numbering scheme consists of three
part numbers.
For the sake of example we will use BIND in the rest of this document.
Current Release 9.4.1:
9 - an architecture number,
.4 - a major release number, and
.1 - a minor release number.

Within the BIND 9 architecture series, major releases can and usually do
include "feature" changes (new functionality, new named.conf syntax,
etc). Minor releases do not include feature changes, only bugfixes.

Minor releases fall into 2 categories:  1) Security releases and 2)
roll-up bugfix releases.

1)Security releases generally consist of the absolute minimum necessary
change from the previous release making it easier for users to
upgrade quickly, as security releases are usually time critical.

2)Roll-up bugfix releases include whatever bugfixes have accumulated
since the last release, and can include a large number of changes; most
of these changes are usually relatively small, but the volume of new
code in a roll-up bugfix release is generally much larger than in a
security release.

Security releases are unique in that the schedule for security
releases is largely beyond our control.  ISC ships a new security
release as soon as we discover a security-related
vulnerability crucial enough to need one.

Many organizations that use our code have rules of one kind or another
about how often they can upgrade to new releases from vendors, so
unscheduled releases are problematic.   The current version numbering
scheme also makes it hard for users who have not been following
closely to tell the difference between security releases and roll-up
bugfix releases.

To facilitate the upgrade process, we will begin calling security
releases "patch" versions.  Version numbers for patched releases will
include the same three part version number with an appended patch
number.  Thus, the first patch to BIND 9.4.1 would be numbered BIND 9.4.1p1.

Security patches will be released both as patches (diff output
suitable for use with the "patch" program) and also as tarballs.
security patches will generally be the minimal change necessary to fix
the security problem, so that users whose code vetting process
requires them to read every new or changed line of code will be able
to incorporate security-related bugfixes quickly.

Roll-up bugfix releases will continue as before as minor releases
under the old version numbering scheme. Additionally,roll-up bugfix
releases will include any security patches since the previous full
(major or minor) release.  So, for example, BIND 9.4.2 would include
whatever patches were in BIND 9.4.1p1.

We realize that any change to the version numbering of an existing
product creates a certain amount of angst and confusion, but we think
and hope that this revised version numbering scheme will be better for
our users in the long run.  Thank you for your patience and continued
support.