Re: [Distutils] RFC : Version comparison
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.
2009/5/14 P.J. Eby <pje@telecommunity.com>:
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) Regards Tarek
participants (2)
-
P.J. Eby -
Tarek Ziadé