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
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.