
At 11:12 AM 4/22/2009 +0200, Tarek Ziadé wrote:
Hi,
We worked during Pycon on version comparisons. Distutils has one but it is a bit strict, setuptools has another one, but it's a bit heuristic.
We would like to propose the inclusion for Python 2.7 of a new version comparison algorithm, based on the discussion Fedora, Ubuntu and Python people had. The plan would be to deprecate the current one (which is not really used anyway) and provide, promote this one.
Trent Mick took the lead on this work at the end of Pycon, and worked on a prototype.
It's explained here, and there's an implementation (I've put it at the top of the page for conveniency):
http://wiki.python.org/moin/Distutils/VersionComparison
Please comment,
I don't see how it can manage, e.g. a development version of a postrelease, with an SVN rev or date stamp on it. Such versions might not be found on PyPI or on RPMs, but would be needed in development. (Btw, the wiki page pseudo-regex doesn't match what the code actually parses, either.)

2009/4/22 P.J. Eby <pje@telecommunity.com>:
I don't see how it can manage, e.g. a development version of a postrelease, with an SVN rev or date stamp on it. Such versions might not be found on PyPI or on RPMs, but would be needed in development.
So, instead of having 'dev' and 'post', we would require a third case for "pos+dev" version so (dev|post)N+ could become, ((dev|post)N+)|(postN+devN+) example: 1.0.dev459 < 1.0 < 1.0.post456dev463 < 1.0.post456 < 1.0.post489
(Btw, the wiki page pseudo-regex doesn't match what the code actually parses, either.)
i'll check it thx
-- Tarek Ziadé | http://ziade.org

(Btw, the wiki page pseudo-regex doesn't match what the code actually parses, either.)
Current: N.N[.N]+[abc]N[.N]+[.(dev|post)N+] Admittedly that is just trying to be illustrative without being too "syntax-y", but perhaps it is more confusing than helpful. Ultimately I think the docs might be most helpful by just giving examples of valid version strings for different use cases. Something like: Basic versions: 1.0 # there must be at least two numbers (e.g. just "1" is not allowed) 1.5.3.2 # any number of dotted segments more than two are allowed Alphas, betas and release candidates (they must be numbered): 1.0a1 # the first alpha on the way to "1.0" 3.1b1 # the first beta 5.0c3 # the third release candidate for "5.0" Any number of additional dotted segments are allowed 1.0a1.1 # a quick update to the "1.0a1" was necessary (personal note: I'd tend to do a "1.0a2" release, but sometimes that might not be feasible) ... and so on describing the use cases for "dev" (pre-) releases and "post" releases. -- Trent Mick trentm@gmail.com

I don't see how it can manage, e.g. a development version of a postrelease, with an SVN rev or date stamp on it. Such versions might not be found on PyPI or on RPMs, but would be needed in development.
I had thought the use cases for dev- and post- releases *was* to use an SVN (or other SCC systems') rev or a date stamp, thus meaning there would be no need for handling "a development version of a post-release". Perhaps I'm just not seeing it though, I haven't been involved with a project that does post-releases. Can someone describe a concrete example? Trent -- Trent Mick trentm@gmail.com

Sorry to post again that mail, but it seems that this is the last remaining issue for the versionning proposal. Phillip, could you check my proposal for your development versions of postreleases use case ? thx On Thu, Apr 23, 2009 at 11:19 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
2009/4/22 P.J. Eby <pje@telecommunity.com>:
I don't see how it can manage, e.g. a development version of a postrelease, with an SVN rev or date stamp on it. Such versions might not be found on PyPI or on RPMs, but would be needed in development.
So, instead of having 'dev' and 'post', we would require a third case for "pos+dev" version
so (dev|post)N+ could become, ((dev|post)N+)|(postN+devN+)
example:
1.0.dev459 < 1.0 < 1.0.post456dev463 < 1.0.post456 < 1.0.post489
(Btw, the wiki page pseudo-regex doesn't match what the code actually parses, either.)
i'll check it thx
-- Tarek Ziadé | http://ziade.org
-- Tarek Ziadé | http://ziade.org
participants (3)
-
P.J. Eby
-
Tarek Ziadé
-
Trent Mick