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

[David Cournapeau]

Tres Seaver wrote:
> Ben Finney 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.
>
>
> > "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
.
>
> -1:  "practicality beats purity" here:  there is *no* case in which an
> alpha version should *ever* sort after the final release with the
> corresponding number.  

I thought improved support for OS packagers was one of the main
rationale for this version scheme ? In that case, the above scheme is
totally incompatible with what at least dpkg, and I would assume rpm,
use for version comparison:

http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

I am a bit confused, because I thought several packagers were there at
PyCon to discuss about this ?

David