> Because the version number is just more complicated? The details have
been ...
Nope, the whole point is it shouldn't. If that has to be enforced why
adding "marketing alert" to it? Why choosing something complex over
something simple?
In the correct world (mine where unicorns live freely) I should be able
to retrieve the code that goes with an installed package just using that
version and rebuild it (in a repeatable way)!
Or you're talking about a "label" instead a version? In which case you
shouldn't really compare them!
Ronald Oussoren wrote:
On 4 Feb, 2013, at 17:00, a.cava...@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 the version number is just more complicated? The details have been
discussed at length (and then some more) on this list, but just consider the
common
scheme of alpha, beta and release-candidate releases.
Without special support you'd end up with a version 1.0 being older than 1.0rc1.
Ronald
On Mon 04/02/13 16:31, "Philippe Ombredanne" pombreda...@nexb.com wrote:
On Mon, Feb 4, 2013 at 2:10 PM, Nick Coghlan<ncoghlan@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@n
exB.com
DejaCode Enterprise at http://www.dejacode.com
nexB Inc. at http://www.nexb.com
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
