2009/5/14 P.J. Eby firstname.lastname@example.org:
At 10:19 AM 5/14/2009 +0200, Tarek Ziadé wrote:
from a setuptools user point of view, the benefit I can see is that they will have better version numbers
Better how? That was my question. I personally find the common version patterns in use (e.g. '-' and '-r' for post-releases) less clunky and easier to read than 'post'.
Removing the usage of "-" is important for debian packagers for example.
I also don't care for '.' in front of dev and post. So, I don't see the changes as all "better" from a readability POV.
That's not to say it's a bad thing, if it gives other benefits. But it has not been stated what the benefits are supposed to be.
True, we didn't post that, we just talked about it during Pycon,
Maybe Matthias and Toshio can write down a detailed list of the issues with setuptools version system, to make them clearer.
Now I suppose setuptools will have to propose both for some time,
I don't see why. AFAICT, RationalVersion is a strict subset of the syntax supported by setuptools, and most setuptools versions in use should be convertible.
e.g. switch to scrict=True at some point.
But what I am scared of is : who will work on setuptools side ? can you bless someone to do the work when we agree on a common roadmap ?
I don't see that there is any work *to* do in setuptools core, since RationalVersion is a strict subset, and we have setup-argument validation providers already. I.e., anyone can make a plugin that validates or converts a setup(version="...") string, put it on sys.path, and force canonical versions.
Ok that's great then. (the svn support would need the same extendability)