[Distutils] PEP 426, round 733 ;)

[Nick Coghlan]

On 5 Feb 2013 02:01, <a.cavallo at cavallinux.eu> wrote:
>
> I agree *completely* with Philippe here.
>
> If a version standard will be enforced what's the point of making it more
> complicated that a sequential number or something along x.y.z? In the end
that's
> what the version number is.

Because to get broad adoption we need a scheme that is sufficiently
expressive to cover the development practices of the vast majority of
current PyPI projects.

Lexicographic sorting doesn't cut it, while the scheme that was thrashed
out a few years ago in PEP 386 does. The only problem was the sorting
position of top level "dev" releases (which didn't match existing
practice), and that's why ".dev" joined no suffix at all and ".post" as
being sorted out of lexical order.

No sane project would use all of the possible combinations. In particular,
dev and post releases of alphas, betas and release candidates are expected
to be rather rare. However, when you take the superset of all those
individually simpler project specific schemes (excluding the unorderable
ones like code names), this kind of thing is what you're going to get.

>
>
>
>
> On Mon 04/02/13 16:31, "Philippe Ombredanne" pombredanne at nexb.com wrote:
> > On Mon, Feb 4, 2013 at 2:10 PM, Nick Coghlan <ncoghlan at g
> > mail.com> wrote:
> > As usual, PEP inline below and on the web
> > at
> > http://www.python.org/dev/peps/pep-0426/
> >> Version scheme
> > > ==============
> > > Version numbers must comply with the following
> > scheme::
> >     N.N[.N]+[{a|b|c|rc}N][.postN][.devN]
> > >
> > > Version numbers which do not comply with this scheme
> > are an error. Projects
> > which wish to use non-compliant version numbers must
> > restrict themselves
>
> > IMHO a version (or eventually its dot-separated segments with
> > precedence from left to right) should increase when sorted
> > lexicographically so it is never ambiguous for a human reading a list
> ....
> > Are we trying to make a version -- which is an engineering must --
> > into something that  has also some semantics about the level of
> > completion of a project or some "marketing" alert on the level of
> > maturity of a software release? Could we stay instead in the realm of
> > engineering?
> >
> > I think that trying to inject things like alpha, beta, post,  dev,
> > release candidates and the likes in this is trying to bake in too many
> > things that are eventually just the practices of some  projects and
> > should not be the frozen practice baked in a PEP.  Instead, this
> > should be left to project authors to define their own scheme as long
> > as it sorts lexicographically (eventually by segments, with precedence
> > from left to right).
> >
> > --
> > Philippe Ombredanne
> >
> > +1 650 799 0949 | pombredanne at n
> > exB.com
> DejaCode Enterprise at http://www.dejacode.com
> nexB Inc. at http://www.nexb.com
> _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > http://mail.python.org/mailman/listinfo/distutils-sig
> >
> >
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130205/708c81ea/attachment.html>