Version numbers on trunk and maintenance branches
July 19, 2008
The release process that I wrote for the Zope subversion repository states that a library’s version number on the trunk or a release branch should always be the next release version number applicable to that branch. For instance, if
zope.interface 3.4.1 were just released from the 3.4.x branch, the version number of
zope.interface on that branch should read 3.4.2dev.
Let me explain why I suggested this practice and, despite much critique, still maintain it’s makes the most sense.
First of all, the setuptools documentation states:
Note: the project version number you specify in setup.py should always be the next version of your software, not the last released version.
So it’s a convention that seems to be generally suggested. That doesn’t necessarily mean it’s a good idea, though.
What makes it a good idea is the fact that when you get a checkout of the trunk or a development branch, the version number is actually meaningful, due to setuptools’ version semantics
3.4.1 < 3.4.2dev < 3.4.2
So, a development egg of
zope.interface 3.4.2dev will for instance satisfy a version requirement like “
zope.interface > 3.4.1“. For example, say you wanted to temporarily deploy from a subversion checkout. I had to do this to get my PyFlakes running with Emacs. The latest release PyFlakes 0.2.1 wasn’t good enough because something got fixed on the trunk. So I got a trunk checkout and did a
python setup.py install
into a virtualenv. Surely enough, the trunk’s version number was still pointing to 0.2.1. So I ended up with
pyflakes-0.2.1-py2.4.egg in my site-packages and no way to tell it from the actual 0.2.1 release. (Yes, I know there’s some setuptools parameter than can let you build versions like 0.2.1-r48292, and those would be fine, if they were configured to occur on the trunk automatically.) So that’s why not only bumping the version number to the next release but also adding the “
dev” marker to tell development eggs or snapshots apart from actual release (and prevent people from releasing from the trunk!) is a good idea.
To conclude, I think bumping the version number to the next or at least the next anticipated release (it’s ok if you don’t get the version number right the first time) and adding a dev marker is not only a good idea, I think it’s pretty much the only way to get the version number semantics of development eggs right (unless you use r34234 suffixes which have other problems). Of course, I’m willing to be convinced otherwise if alternate solutions achieve the same semantics. Comment away!