[Distutils] version scheme: a case for dropping ".devNNN" and ".postNNN"
Ben Finney
ben+python at benfinney.id.au
Sun Jun 14 01:46:17 CEST 2009
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
More information about the Distutils-SIG
mailing list