On Sun, 14 Jun 2009 09:46:17 +1000, Ben Finney <[email protected]>
wrote:
Eric Smith <[email protected]> writes:
Ben Finney wrote:
> If the version comparison semantics are such that simple “compare
> non-digits per ASCII, compare digit sequences as integers” works
> within a component, I'm not aware of any distribution downstream
> that can't just use them as-is. What specific problems can you see
> with that?
I think the "count up to" a release version is the problem, and the
only one I can think of. Before Twisted releases 8.2.2, do they really
need to call all of the versions 8.2.1.99.1, 8.2.1.99.2, etc., to
avoid confusion with a possible 8.2.1 release? Don't you think some
information is lost by not conveying "this will become 8.2.2 when it
is the release version"?
Why is it necessary for a version string to convey a prediction about
what *future* version strings will mean? That seems to me to be an
overloading that costs a significant amount of complexity, and is
unnecessary since a different version string can be chosen that meets
the intentional sequence position anyway.
I think there was some confusion here. Twisted doesn't use the "count up
to" a release scheme (which is the .devNNN scheme). It uses the "count
away from" a release scheme (ie, the equivalent of the .postNNN scheme,
if I understand correctly).
The current "in development version" of Twisted is 8.2.0r27007. The last
release was Twisted 8.2.0. It is expected, but not guaranteed, that the
next release of Twisted will be 9.0.0.
Projects that use the .devNNN scheme, though, rather than something like
the .postNNN scheme, do have to deal with this, though. It seems to me
that this is pretty common, as release candidates will necessarily fall
into this category (however, it is far past my bed time, so if I have
forgotten about some corner of things, apologies for the noise).
[snip]
Paul Moore <[email protected]> writes:
One other aspect of standard practice that I just realised your rules
don't cover is where version strings differ in length. The normal
lexicographic "shortest is earliest" rule doesn't work properly:
1.2a1 vs 1.2 (I hope everyone agrees that 1.2a1 is earlier)
No, I don't agree. Those each represent two components, where the first
is identical and the second is different; and when comparing the two
different components, I would expect “2” to be earlier than “2a1”.
This seems to be the crux of the use case. 1.2a1 obviously should come
before 1.2. :) Forcing the first alpha release of 1.2 to be 1.1.999.a1
or something like that would be very unfortunate, even though from some
perspectives it's simpler than the reverse.
Jean-Paul
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
