On Tue, Feb 5, 2013 at 6:44 AM, Nick Coghlan wrote:
> The version scheme is not going to change. The point of PEP 386 was,
> to a very large extent, to define a scheme that *existing PyPI
> projects* either already comply with, or will require only minor
> cosmetic changes to comply with (such as
On Thu, Feb 7, 2013 at 11:50 AM, Donald Stufft wrote:
> I'm not against the change in particular though. The reference impl in
> distutils2
> protected against really high version numbers, I'm not sure what the logic
> behind
> that was except for protecting against "dates" as a version number. Mi
On Wednesday, February 6, 2013 at 8:23 PM, Nick Coghlan wrote:
> The one *actual* change I will be making to the version scheme in the
> next draft is to allow Fedora/Firefox/Chrome style version numbering
> where there are only major releases, with no minor marker. Since the
> version scheme also
On Thu, Feb 7, 2013 at 4:17 AM, wrote:
> Mine wasn't an objection: it was a plain refusal.
Your preferred lexicographically sorted scheme is completely compliant
with both PEP 386 and PEP 426. It merely expects users to write their
requirements as ">= 1.1, < 1.1.90" if they don't want to acciden
Mine wasn't an objection: it was a plain refusal.
On Wed 06/02/13 18:00, "Daniel Holth" dho...@gmail.com wrote:
> On Wed, Feb 6, 2013 at 11:37 AM, wrote:
> Feel free to adopt whatever you think is the "best" practice: I dont
> understand
> whats wrong with 1.1.99 instead the "magic" 1.2b2.
>
>
On Wed, Feb 6, 2013 at 11:37 AM, wrote:
> Feel free to adopt whatever you think is the "best" practice: I don't
> understand
> what's wrong with 1.1.99 instead the "magic" 1.2b2.
>
> I followed these "lengthy discussions" .. if an agreement was found and was
> technically sound why do you think p
Feel free to adopt whatever you think is the "best" practice: I don't understand
what's wrong with 1.1.99 instead the "magic" 1.2b2.
I followed these "lengthy discussions" .. if an agreement was found and was
technically sound why do you think people still arguing about that? And we're
talking yea
On Tue, Feb 5, 2013 at 10:53 AM, Donald Stufft wrote:
> On Tuesday, February 5, 2013 at 10:49 AM, a.cava...@cavallinux.eu wrote:
>
> Or until when somebody will explain if X.Y.devN comes before of after
> X.Y.N...
>
> Easy, before.
Which is explained in the PEP pretty clearly I thought. But if yo
On Tue, Feb 5, 2013 at 9:08 AM, Daniel Holth wrote:
> On Tue, Feb 5, 2013 at 7:54 AM, Donald Stufft
> wrote:
>>
>> On Tuesday, February 5, 2013 at 5:35 AM, a.cava...@cavallinux.eu wrote:
>>
>> Ideally it would be something that connects to the source revision number
>> (as in
>> subversion) or th
On Tuesday, February 5, 2013 at 10:49 AM, a.cava...@cavallinux.eu wrote:
> Or until when somebody will explain if X.Y.devN comes before of after X.Y.N...
>
>
Easy, before.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/
I respectfully disagree, for what it matters I will ignore the whole stuff.
These PEPs have been around for ages. And I supsect they will be around until
the
end of times.
Or until when somebody will explain if X.Y.devN comes before of after X.Y.N...
On Tue 05/02/13 15:44, "Nick Coghlan" ncogh.
On Wed, Feb 6, 2013 at 1:06 AM, Philippe Ombredanne
wrote:
> On Tue, Feb 5, 2013 at 3:08 PM, Daniel Holth wrote:
>> The "marketing pre-release" feature exists to allow publishers to put
>> immature versions of their software on pypi where they can be easily
>> downloaded. Recently SQLAlchemy did
On Tue, Feb 5, 2013 at 3:08 PM, Daniel Holth wrote:
> The "marketing pre-release" feature exists to allow publishers to put
> immature versions of their software on pypi where they can be easily
> downloaded. Recently SQLAlchemy did this but had to delete the beta release
> from pypi because too m
On Wed, Feb 6, 2013 at 12:15 AM, wrote:
>
> Not quite correct: 1.1.x and 1.2.x are two separate branches in Django.
>
> So along the 1.1.x branch the timestamp identifies what comes first and after.
> Think of a plane where the coordinates are the timestamp and the branch: to
> compare you need f
Not quite correct: 1.1.x and 1.2.x are two separate branches in Django.
So along the 1.1.x branch the timestamp identifies what comes first and after.
Think of a plane where the coordinates are the timestamp and the branch: to
compare you need fix one of the two (the branch in this case).
BTW th
On Tuesday, February 5, 2013 at 9:08 AM, Daniel Holth wrote:
> What if we replaced this with semver? Last fall I argued that PEP 386 sucked
> and that we should use semver. Unfortunately semver is less similar to the
> longstanding sort order than the proposed scheme, there would be a lot of -
>
On Tue, Feb 5, 2013 at 7:54 AM, Donald Stufft wrote:
> On Tuesday, February 5, 2013 at 5:35 AM, a.cava...@cavallinux.eu wrote:
>
> Ideally it would be something that connects to the source revision number
> (as in
> subversion) or the integral id or even a timestamp (that's what an exported
> ver
On Tuesday, February 5, 2013 at 5:35 AM, a.cava...@cavallinux.eu wrote:
> Ideally it would be something that connects to the source revision number (as
> in
> subversion) or the integral id or even a timestamp (that's what an exported
> version must be).
Timestamp or reversion number is not overa
I followed in the past the discussion that lead to the pep. I've lost any
interest in it because I had a clear perception there was more interest in
"splitting the hair" that solving any real problem, *and that was years ago*.
That alone should trigger some doubt about the validity of the points m
On 4 Feb, 2013, at 20:59, Antonio Cavallo wrote:
> > 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 sim
On 5 Feb 2013 02:01, 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
Nick Coghlan gmail.com> writes:
>
> (I think we're getting pretty close now...)
>
I've implemented parsing -> tuple for versions as specified in the PEP, to test
parsing and sorting:
https://gist.github.com/4709696
Please let me know if you spot anything wrong with the code.
Regards,
Vinay
> 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)
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.
B
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.
On Mon 04/02/13 16:31, "Philippe Ombredanne" pombreda...@nexb.com wrot
On Mon, Feb 4, 2013 at 10:31 AM, Philippe Ombredanne
wrote:
> On Mon, Feb 4, 2013 at 2:10 PM, Nick Coghlan 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
On Mon, Feb 4, 2013 at 2:10 PM, Nick Coghlan 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 w
(I think we're getting pretty close now...)
As usual, PEP inline below and on the web at
http://www.python.org/dev/peps/pep-0426/
Diff from the previous version is here (the abstract is fixed in the
next commit): http://hg.python.org/peps/rev/7f36cb23fb6d
>From the commit message:
- include an
28 matches
Mail list logo
