I never quite understood what 1.2beta ever meant in a typical life cycle in first.
Source code *has* a natural sequential evolution nature (call it a commit time stamp, a scm version number etc.): even branches can be seen sequential walk along a "timeline". For that reason I don't think enforcing a __release__ tag being a let's say 3 non decreasing digit would be a bad idea: "rebels" willing to use things like 1.2b can keep still stuff that in (IMHO) the wrong __version__ variable. If __release__ is not defined it can default to 0.0.0 (so holding the backward compatibility. On Tue 29/01/13 11:25, "Vinay Sajip" vinay_sa...@yahoo.co.uk wrote: > Daniel Holth <dholth <at> gmail.com> writes: > > > It hurts to have multiple version schemes in > concurrent use. > Agreed, but I don't see how you can avoid it; even if all projects switch > over to a single scheme in the future, you still have the problem of past > versions. You can be sure, too, that for many projects, their dependencies will > use schemes which may not be mutually compatible with each other (excepting, > of course, if you treat them all as having the "legacy" version scheme - that, > of course, fits everything, as it is sufficiently liberal). > > Regards, > > Vinay Sajip > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > > _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
