Quoth Andrew M. Kuchling, on 10 December 1998:
Disagreement; I'd vote for mechanism, not policy. For example, recently I went through 3 pre-releases of xml-0.5; they could have been called 0.5a{1,2,3}. ILU's been at 2.0a{1-12}, and I have no idea if the developers ever plan to go to beta. Different developers use version numbers differently, in ways that are consistent in the large but inconsistent in small details.
Module developers are perfectly free to use illogical version numbers if they wish. I certainly don't intend to enforce through code the version number *guidelines* that I proposed, nor do I intend to check for the version numbers occupying the "illogical" subsets of version-number-space. I just wanted to point out the possible consequences of *that particular* set of guidelines. If anyone has suggestions for version number guidelines that don't have unexpected consequences, I'd like to hear 'em. (Of course, such guidelines should be short, simple, and obvious. That's what I like about my proposal.)
A side note: for the XML package, I think things are getting to the point that I want to create a fake build tree (the blib/ idea) in order to allow running the test suite without having to actually perform the installation. So, is there any implementation work that can be done?
Yeah, the distutils.build module. It would have to be told various lists of source files (for a start: .py, ancillary .c files, and extension .c files) and then would Do The Right Thing: copy .py into blib, compile to .py and .po, compile all .c files, and link ancillary .o with extension .o to make .so. (Platform independence can come later.) Of course, we haven't really looked at the existing extension-building systems, e.g. the interface put on the table by John Skaller. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913