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

[Ben Finney]

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.


"P.J. Eby" <pje at telecommunity.com> writes:

> Please explain how you intend to designate "development" versions that
> compare less than the equivalent non-development versions in your
> scheme.

    >>> (V("0.9")
    ... < V("0.9.0")
    ... < V("0.9.1")
    ... < V("0.9.a")
    ... < V("0.9.a2")
    ... < V("0.9.post123")
    ... < V("0.9b")
    ... < V("0.10")
    ... < V("0.999.0.dev-r925")
    ... < V("0.999.0.dev-r1357")
    ... < V("0.999.0.dev-r2468")
    ... < V("0.999.0.dev-r3579")
    ... < V("0.999.alpha1")
    ... < V("0.999.alpha2")
    ... < V("0.999.beta1")
    ... < V("0.999.rc1")
    ... < V("0.999.rc2")
    ... < V("1.0"))
    ...
    True

"P.J. Eby" <pje at telecommunity.com> writes:

> I can *almost* see a case for dropping "post" […]
> 
> However, I do not see an equivalent case for dropping "dev", since
> it's an important part of development workflows, and I don't see any
> way to simulate it in an an otherwise-linear scheme.

I don't understand. You see that there's a scheme for generating version
strings that compare in a linear sequence, yet you can't see how to
generate a version string that will compare at a specific point in that
linear sequence?

For my part, I don't see what it is about these workflows that requires
a special-cased token in the version string. Why can't the workflow
simply use version strings that compare linearly as specified?


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

-- 
 \         “Please leave your values at the front desk.” —hotel, Paris |
  `\                                                                   |
_o__)                                                                  |
Ben Finney