On Sun, Feb 3, 2013 at 3:23 PM, Marcus Smith wrote:
>
>> No, all the "dev" releases will sort before all the "a" releases (and
>> PEP 426 will be explicit about that).
>
>
> ok, there's top-level "dev" and then there's ".dev"
> see my other comments about being unclear what you're saying given the
> No, all the "dev" releases will sort before all the "a" releases (and
> PEP 426 will be explicit about that).
ok, there's top-level "dev" and then there's ".dev"
see my other comments about being unclear what you're saying given the
typos.
maybe rewrite the pep386 example for us in this email
On Sun, Feb 3, 2013 at 9:06 AM, Marcus Smith wrote:
>
>> a top level "dev" release should be sorted before the first alpha
>> release
>
>
> ok, so applying this to the example in pep386 (and your comment about
> interpreting a top-level "dev" as "a0.dev"), the sorting would be like this?
>
>ne
> with the modification that when a tool sees an unqualified "X.Y.dev"
> or "X.Y.Z.dev" release (i.e. any release where the "dev" immediately
> follows the purely numeric component of the version), that should be
> reinterpreted as if there was an "a0" component (as in "X.Y.a0.dev" or
> "X.Y.Z.a0.d
> The problem with allowing both "pre" and "dev" (as suggested last
> year) is that it's completely unclear how to sort them when they
> appear at the same level. Does dev come before pre or after?
here's the suggestion I think from the old thread.
>* "dev" should be moved to a "main"*>* release
> a top level "dev" release should be sorted before the first alpha
> release
>
ok, so applying this to the example in pep386 (and your comment about
interpreting a top-level "dev" as "a0.dev"), the sorting would be like
this?
new... V('1.0dev1')
new... < V('1.0a0.dev2')
new
On Thursday, January 31, 2013 at 9:10 AM, Nick Coghlan wrote:
> So, here's my suggestion for a way forward:
>
> 1. PEP 426 incorporates the "new versioning algorithm" section from
> PEP 386 directly rather than by reference, with the clarification that
> a top level "dev" release should be sorted
On Thu, Jan 31, 2013 at 9:10 AM, Nick Coghlan wrote:
> On Thu, Jan 31, 2013 at 9:39 PM, Donald Stufft
> wrote:
> > On Thursday, January 31, 2013 at 1:20 AM, Nick Coghlan wrote:
> >
> >
> > Correct. The desire is still to migrate to a more formal versioning
> > scheme, hence PEP 386 by default if
On Thu, Jan 31, 2013 at 9:39 PM, Donald Stufft wrote:
> On Thursday, January 31, 2013 at 1:20 AM, Nick Coghlan wrote:
>
>
> Correct. The desire is still to migrate to a more formal versioning
> scheme, hence PEP 386 by default if no Version-Scheme is specified.
> However, I don't want "but what if
Sounds like a :: and a "If not specified, pep386 should be assumed" are the
only things missing from this PEP.
On Thu, Jan 31, 2013 at 6:39 AM, Donald Stufft wrote:
> On Thursday, January 31, 2013 at 1:20 AM, Nick Coghlan wrote:
>
>
> Correct. The desire is still to migrate to a more formal vers
On Thursday, January 31, 2013 at 1:20 AM, Nick Coghlan wrote:
>
> Correct. The desire is still to migrate to a more formal versioning
> scheme, hence PEP 386 by default if no Version-Scheme is specified.
> However, I don't want "but what if PEP 386 doesn't handle my
> pre/post/whatever release nam
On Wed, Jan 30, 2013 at 10:54 PM, Paul Moore wrote:
> On 30 January 2013 12:32, Vinay Sajip wrote:
>> I'm not sure I understand this point. Shouldn't that default be
>> "pkg_resources",
>> given that all the existing distributions on PyPI will work with that scheme
>> and
>> not have the Versio
> I'm not sure I understand this point. Shouldn't that default be
> "pkg_resources",
> given that all the existing distributions on PyPI will work with that
> scheme and
> not have the Version-Scheme present in their metadata?
>
>
afaik, all existing distributions will be Metadata-version:1.0 (or 1
On 30 January 2013 12:32, Vinay Sajip wrote:
> I'm not sure I understand this point. Shouldn't that default be
> "pkg_resources",
> given that all the existing distributions on PyPI will work with that scheme
> and
> not have the Version-Scheme present in their metadata?
I assumed that the idea
Nick Coghlan gmail.com> writes:
> will likely need to rely on pkg_resources, or at least a copy of
> pkg_resources.parse_version(), in order to support packages that
> request this version comparison method).
There's a function in distlib, distlib.version.legacy_key(), which sorts
compatibly wit
On Wed, Jan 30, 2013 at 3:02 AM, Daniel Holth wrote:
> Version-Scheme (optional)
> :
>
> A string specifying the sorting method for this distribution's version
> numbers. Although straightforward version numbers tend to sort the same in
> each scheme, there is disagreement
>
>
> Actually, given that the version scheme is a new field, why not duck
> the issue and just say that a missing version scheme implies
> "legacy"/"setuptools"? That'll be the de facto position anyway.
>
> Paul.
>
I'm partial to this idea.
i.e. if you want to specify that you're intending to be
>
>
> Version-Scheme (optional)
> :
>
> A string specifying the sorting method for this distribution's version
> numbers. Although straightforward version numbers tend to sort the same in
> each scheme, there is disagreement about how to sort patch releases and
> versions h
Minor editing changes, Version-Scheme added.
PEP: 426
Title: Metadata for Python Software Packages 1.3
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth
BDFL-Delegate: Nick Coghlan
Discussions-To: Distutils SIG
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created:
On Tue, Jan 29, 2013 at 10:19 AM, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
> > (Warning - bikeshed discussion. I won't prolong the debate beyond this
> > one comment. I'm happy for Nick to simply pronounce on this). I'm not
> > sure I like having "setuptools" as a name mandated in a P
Paul Moore gmail.com> writes:
> (Warning - bikeshed discussion. I won't prolong the debate beyond this
> one comment. I'm happy for Nick to simply pronounce on this). I'm not
> sure I like having "setuptools" as a name mandated in a PEP (just
> because it's a 3rd party package). Does the distutil
On 29 January 2013 14:28, Daniel Holth wrote:
> The names will be "setuptools" and "pep386" referring to the sort method
> inside pkg_resources and the pep 386 method.
(Warning - bikeshed discussion. I won't prolong the debate beyond this
one comment. I'm happy for Nick to simply pronounce on thi
On Tue, Jan 29, 2013 at 8:42 AM, Paul Moore wrote:
> On 29 January 2013 12:29, Nick Coghlan wrote:
> > The specific intent of adding Version-Scheme is to relax the version
> > numbering requirement from "you *must* use PEP 386 version numbering"
> > to "you *should* use PEP 386 version numbering
On 29 January 2013 12:29, Nick Coghlan wrote:
> The specific intent of adding Version-Scheme is to relax the version
> numbering requirement from "you *must* use PEP 386 version numbering"
> to "you *should* use PEP 386 version numbering for new projects, but
> if you're already using a different
On Tue, Jan 29, 2013 at 9:49 AM, Donald Stufft wrote:
> On Monday, January 28, 2013 at 6:44 PM, Vinay Sajip wrote:
>
> I would add to the currently supported values "semantic"
> (http://semver.org/)
> as this scheme is widely used and is easy to support.
>
> Currently, distlib supports a number of
Daniel Holth gmail.com> writes:
> It hurts to have multiple version schemes in concurrent use.
Agreed, but I don't see how you can avoid it; even if all projects switch over
to a single scheme in the future, you still have the problem of past versions.
You can be sure, too, that for many project
I would very much like to move everyone to semver (in practice a subset
that is compatible with the file naming conventions, you probably won't get
far if your version contains a dash -). The setuptools behaviour is the
most practical scheme in use in the Python community. I've made most of the
sug
On Monday, January 28, 2013 at 10:58 PM, Daniel Holth wrote:
> I would very much like to move everyone to semver (in practice a subset that
> is compatible with the file naming conventions, you probably won't get far if
> your version contains a dash -). The setuptools behaviour is the most
> pr
On Monday, January 28, 2013 at 6:44 PM, Vinay Sajip wrote:
> I would add to the currently supported values "semantic" (http://semver.org/)
> as this scheme is widely used and is easy to support.
>
> Currently, distlib supports a number of version schemes:
>
> "legacy" - setuptools ordering - most
29 matches
Mail list logo
