[asterisk-dev] [policy] DAHDI version numbers

[Shaun Ruffell]

The historical convention for assigning Zaptel version numbers had been to use
an A.B.C[.D] format.

* The A number for major revisions.

* The B number indicated the version of Asterisk that was supported.  Zaptel
   1.2.x supported Asterisk 1.2.x and Zaptel 1.4.x supported
   Asterisk 1.4.x.

* The C number was for major changes and new features and bug fixes.

* A D number sometimes was used for minor bug fixes that subjectively didn’t
   warrant a bump in the C number.

With the release of DAHDI, the convention of indicating Asterisk version
support in the DAHDI version number is no longer the convention. DAHDI 2.0.0
supports both Asterisk 1.4 (later versions) and Asterisk 1.6.  Since DAHDI is
now decoupled from the Asterisk version number I would like to clarify and
request any comments on another A.B.C[.D|-rcX] format to use for DAHDI, both
linux and tools.

* The A number is for major changes that potentially change the concept of
   DAHDI and should rarely change.

* The B number is for new features or functions that may require a change in
   some other dependent package.  This might be a change in dahdi/user.h that
   breaks Asterisk compilation.  This might also be the addition of a new
   driver or feature that requires changes in the system configuration and/or
   asterisk configuration script in order to take advantage of.  Basically,
   users should not necessarily expect to be able to move between various B
   releases without needing to make some other system change. However it is
   important to note that this wouldn’t always be the case--for example when a
   new driver is added that the user wouldn’t ever use.

* A C number for bug fixes and internal improvements that do not require any
   changes to dependent packages or system configuration files.  A user should
   be able to move between different C versions of a given A.B version without
   requiring any system configuration changes.

* An optional D number for urgent bug fixes that do not require any
   configuration changes and are not significant enough to warrant a cycle of
   release candidates or formal testing.

* An optional release candidate level for a given A.B.C release.  Before
   making an A.B.C release, there will be one or more release candidates that
   will be advertised on asterisk-dev to allow interested parties to test the
   packages before making the A.B.C release and posting the announcement on
   asterisk-users and asterisk-announce.

While the version numbers for dahdi-linux and dahdi-tool have mirrored one 
another to date, this is not necessarily required.

As part of implementing this policy, kpfleming recommended adding both UPGRADE 
and CHANGES files to dahdi-linux so that users have a specific place to go in 
order to learn what changes might need to be made when moving between 
consecutive B versions.  These files are not currently in the 2.0.0 or 2.1.0 
releases, but will be in the next release if this is how we want to proceed.

Finally, changes in either dahdi-linux or dahdi-tools that would cause 
something to break in a package that is not either dahdi-linux or dahdi-tools 
will result in a A.B branch that will receive bug fixes for some period of 
time (TBD) independently of the trunk.  This is essentially the same way 
Asterisk is maintained now and is intended to allow users to receive the 
benefits of bug fixes without a resultant ripple of changes to their entire 
configuration.  However an A.B release that introduces a new feature which 
doesn't break backward compatibility will not result in a separately 
maintained branch.  For example, a user who updates from dahdi-linux 2.0.0 to 
2.1.0 would not by default be required to also update their Asterisk version. 
  Therefore, bug fixes committed to the trunk will not be ported back to a 
2.0.0 branch.

Any thoughts or comments?