Andrew M. Kuchling writes:
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.
I don't see any problem with offering mechanism in the software and a short set of guidelines in documentation. Perhaps the docs should indicate that if the guidelines are not followed, perpetrators will be tossed over... er, they should describe how they are using the parts of the number in their documentation.
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
On this topic, it may make sense for the xml package to be a directory within the package, rather than the package toplevel. So xml-VERSION.tar.gz would expand to: xml-VERSION/ xml/ dom/ sax/ parsers/ utils/ ... doc/ README ...
perform the installation. So, is there any implementation work that can be done?
I think a version number "object" that can handle parsing and comparison is a clear need and fairly straightforward to implement. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191