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/ : ---------------------------------------------------------