[Distutils] recollections of Pycon distutils versioning discussion (part 2)

[Paul Moore]

2009/6/11 Zooko Wilcox-O'Hearn <zooko at zooko.com>:
> If the new "rational version number" definition excludes ".post", and if I
> choose to make Tahoe snapshot version numbers be rational version numbers,
> then I could make snapshots be named e.g. v1.4.1.3908.  Then I would have
> v1.4.1.3909, etc. until one day I would have v1.4.1.3948 and then v1.5.0.
>  The next snapshot would be numbered v1.5.0.3949.  I would hope that people
> who are looking for stable releases don't find the v1.5.0.3949 tarball
> (since it isn't on PyPI), or if they do find it that they realize from the
> extra long version number that it is a snapshot instead of a stable release.
>
> I'm willing to change my build system to produce $MAJ.$MIN.$MIC.post$COUNT
> instead of $MAJ.$MIN.$MIC-r$COUNT, in order to achieve rationality (i.e., in
> order to make my versions look more like other people's versions and in
> order to be compatible with some hypothetical far-future tool which is picky
> and refuses to use software with irrational version numbers).  I'm not yet
> sure whether I'm willing to change it to $MAJ.$MIN.$MIC.$COUNT.

I really don't fully understand your motivation here (how "stable" a
release is, is more about where you get it from and how it is
advertised, than about the version number) but if it's going to stop
the arguments, let's go with Ben's definition, specified in a previous
email (dot-separated components, each component sorted
alphanumerically, with sequences of digits treated as numbers). Then
you can use .r12345, or .post12345, or even
.helloguysIcanabusethesystem12345. But please don't enshrine specific
fixed strings in the spec.

Paul