[Distutils] version scheme: a case for dropping ".devNNN" and ".postNNN"

[Jean-Paul Calderone]

On Sun, 14 Jun 2009 09:46:17 +1000, Ben Finney <ben+python at benfinney.id.au> wrote:
>Eric Smith <eric at trueblade.com> 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 <p.f.moore at gmail.com> 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