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

[Zooko Wilcox-O'Hearn]

On Jun 11, 2009, at 2:37 AM, Paul Moore wrote:

> 1. From your description of events, and from discussion here, the  
> "post" tag is clearly the least thought through aspect of all this.  
> So a proponent of this should step up to justify why 1.0.5.post3 is  
> required, when 1.0.5.3 is available already.

My motivation is that the leading sequence of numbers is chosen by a  
human to communicate some information such as major rewrite (major),  
feature addition (minor), or bugfix (micro), while the numbers after  
the "-r" or the ".post" are chosen by the version control system to  
simply count patches or give a secure hash of the current tree state  
or whatever.  Another bit of information that we thus encode into the  
version number is whether it is a stable release or a snapshot --  
stable releases don't have a -r$COUNT in their version number.

The current stable release of Tahoe is v1.4.1, as visible on PyPI:  
http://pypi.python.org/pypi/allmydata-tahoe .  The current snapshot  
is v1.4.1-r3908, as visible on our web server: http://allmydata.org/ 
source/tahoe/tarballs/?C=M;O=D .

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.

Regards,

Zooko