[asterisk-dev] [policy] DAHDI version numbers

[Tzafrir Cohen]

On Thu, Dec 11, 2008 at 06:23:54PM -0600, Shaun Ruffell wrote:
> 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 

This is too broad a definition.

What could break?

1. dahdi-linux could break the interface to low-level drivers.


2. The interface between dahdi-linux and dahdi-tools

See e.g.
http://docs.tzafrir.org.il/dahdi-tools/README.Astribank.html#_sys_interface

  Like the procfs interface, this interface is subject to changes and
  should not be considered a stable interface. Please use the DAHDI-perl
  modules and utilities.

Our procfs interface is full of useful debugging information. We cannot
commit to this remaining in the same place. sysfs recoards something
that is very close to the internal structure of the driver. It can and
should change if we figured out we made a mistake.

Another thing that may fall into this category are most of the tonezone
changes in Zaptel 1.4.8-11 (IIRC). The interface to userspace was
changed, but users of libtonezone couldn't care less. ztcfg did need
some modification, but it is part of "the published userspace
interface".

Breaking the interface to internal userspace utilities should not be
taken lightly as well. People may have installed tools and linux
separately. Or they may have a different version of the driver loaded
than the one installed.

Breaking this interface is naturally something that should not be taken
lightly


3. Breaking the published interface

I guess this is something that most users don't like at all. I figure
that at times of distress you should just give them the March of
Progress talk and bring on the bulldozer.

> 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.

I'm not really sure that the 2.0.0 is worth maintaining as a branch. I
think it still has too many initial errors

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir