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'. 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.
that will comply with a documented standard, that is
This isn't actually a change; setuptools also has a documented standard.
usable and understandable by os packagers for example.
I agree that a canonical form is useful. However, if that canonical form can be generated from their existing version numbers, then why should they bother changing?
That's the open question, IOW.
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.
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.