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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.  If we specify the "simple pure" scheme you
propose, nobody will use it, period.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKNZPc+gerLs4ltQ4RAlYOAJ4mtGSe0Iadd6fyiilVO2OVgjwpjwCgth2n
WXOpSORFnStyLWmXPTOP41w=
=hUtJ
-----END PGP SIGNATURE-----