[Distutils] Version numbers for module distributions

[M.-A. Lemburg]

Greg Ward wrote:
> 
> There have been a few rumbles about module version numbering on and off
> the list, and I thought I should bring it all out into the open.  First,
> I think I tossed off a random opinion along these lines:
> 
>    Module version numbers should follow the GNU standard: X.Y.Z, where
>    X is the major version, Y is the minor version, and Z is the
>    patch level.  Alpha and beta versions can be noted by appending
>    "aN" or "bN", where N is any integer.

Sounds ok. There should also be some way to name current snapshots
that are not meant as official distribution, e.g. when I get
bug reports I usually fix them and then put a pre-version on
the server for the envolved people to download and test.

> Now, there should also be semi-formal guidelines on what the different
> components of a version number *for modules* might mean:
> 
>   * a major number of 0 means the module is still being actively
>     developed and, while it may be ready for evaluation, nobody
>     should depend on stability of interface or implementation
>   * a change in the major number beyond 1 means a major change in the
>     interface, possibly not backwards compatible with previous
>     major releases
>   * a change in the minor number means some new functionality has been
>     added in a way that doesn't break the interface
>   * a change in the patch level means bugs have been fixed without
>     adding new functionality
>   * an alpha version (X.Y.Z.aN) is an advance preview of a future
>     release where the interface has not yet stabilized
>   * a beta version (X.Y.Z.aN) is an advance preview of a future
>     release where the interface has stabilized, but known bugs
>     exist and are still being fixed

I don't think that a major version 0 does necessarily imply
alpha status. Many Python extensions start their lifetime
with 0.1 even though they could have started with 1.0 (I guess
Pythoneers are attracted to understatement somehow).

Likewise a change in the major number doesn't necessarily imply a
change in the interface, e.g. a move from 0.9.9 to 1.0.0 may not include
any changes at all.

As a general rule I would not be too specific about the
semantics of the version numbers: modules interdependence
can safely be handled by comparing version numbers (a standard
version number class would be a good idea, IMHO). The module
authors will have to check compatibility anyway, so it's not
the user's problem.

Well, my 0.02e anyway...

BTW: What's the general way of distributing subpackages ? My mxODBC
stuff is getting a little "fat" and I'm thinking of splitting
it up in smaller bits&pieces with a base package and n optional
subpackages.

--
Marc-Andre Lemburg                               Y2000: 386 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------