Re: [Distutils] PEP 426, round 733 ;)
On Tue, Feb 5, 2013 at 6:44 AM, Nick Coghlan ncogh...@gmail.com 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 inserting an extra period to turn X.YdevN into X.Y.devN). [] We already know the most likely outcome of such an effort: people will simply stick with v1.1 of the metadata scheme and continuing to use the existing packaging tools, as migrating to the new ones would require a whole lot pointless busywork to redesign their build processes and workflows. This is in fact the killer argument here, i.e. even though I may not like all that much some of the supported proposed scheme, the practicality of adopting and supporting existing practices trumps IMHO all other arguments. So any objections I brought here about the version schemes are addressed by your answers :) I particularly like the wording you have in the PEP where you explicitly support but do not encourage more byzantine version schemes. -- Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.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
Re: [Distutils] PEP 426, round 733 ;)
On Tue, Feb 5, 2013 at 9:08 AM, Daniel Holth dho...@gmail.com wrote: On Tue, Feb 5, 2013 at 7:54 AM, Donald Stufft donald.stu...@gmail.com 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 version must be). Timestamp or reversion number is not overall useful number for a version and here's why: Django (for example) maintains older versions for a set period of time, If you do it via timestamps than 1.1.1 which happens to be released after 1.2.0 (because of a security issue or glaring bug) will be considered newer. Handwaving the problem away with a source revision number or timestamp ignores a fundamental property of a version What pkg_resources does for sorting is to append final for sorting. So the sorting is really just a, b, c, f. This scheme has been important for 8+ years now. PEP 386, from 2009, narrows the allowed versions. Now the salient part of PEP 386 has been incorporated into Metadata 1.3. 1.0.0a0 1.0.0b0 1.0.0c0 ~= 1.0.0rc0 1.0.0 == 1.0.0f 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 many deployments upgraded to an unstable version without realizing it. Once the tools are updated it will be easy to install a beta release with pip if and only if you specifically ask for it. Yes, this is incredibly useful and I'm glad it was incorporated into this PEP. For the Astropy project for example we recently release version 0.2b2 and we absolutely want to be able to put it on PyPI for users to test out. But as the current situation stands we can't do that because 0.2b2 then becomes the latest version, and the one the gets installed when users expecting the latest stable release do `pip install astropy`. So instead we've just been adding the pre-final release to testpypi and pointing people there. And that's not really meant to be a reliable service. So...yeah. A++ for adding this requirement. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
On Tue, Feb 5, 2013 at 10:53 AM, Donald Stufft donald.stu...@gmail.com 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 you're still not sure there were lengthy discussions on this very mailing list that led to that decision. For what it's worth, there were people who argued the opposite too, but eventually it seems like a consensus was reached. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
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 years not hours to come up with those peps. I like a joke from time to time: python -c 'print 1.2.dev1 1.2.1' - False Even easier in my unicors populated universe. I'll simply ignore anything about those peps, for what it matters. On Wed 06/02/13 17:01, Erik Bray erik.m.b...@gmail.com wrote: On Tue, Feb 5, 2013 at 10:53 AM, Donald Stufft donal d.stu...@gmail.com wrote: On Tuesday, February 5, 2013 at 10:49 AM, a.cav a...@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 you're still not sure there were lengthy discussions on this very mailing list that led to that decision. For what it's worth, there were people who argued the opposite too, but eventually it seems like a consensus was reached. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
On Wed, Feb 6, 2013 at 11:37 AM, a.cava...@cavallinux.eu 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 people still arguing about that? And we're talking years not hours to come up with those peps. Its non-adopted, non-final predecessor turns 8 in April. Unfortunately these kinds of things can be argued endlessly. I like a joke from time to time: python -c 'print 1.2.dev1 1.2.1' - False Even easier in my unicors populated universe. I'll simply ignore anything about those peps, for what it matters In that case after these last objections are dropped let's accept this PEP. Hooray! You can start generating Metadata 1.3 today with bdist_wheel, and distribute already understands the Provides-Extra: feature used to represent setuptools extras. Description-in-body-section is also trouble-free with no changes to pkg_resources. As a comparison, rubygems says ( http://guides.rubygems.org/patterns/#prerelease-gems) Many gem developers have versions of their gem ready to go out for testing or “edge” releases before a big gem release. RubyGems supports the concept of “prerelease” versions, which could be betas, alphas, or anything else that isn’t worthy of a real gem release yet. Taking advantage of this is easy. All you need is one or more letters in the gem version. For example, here’s what a prerelease gemspec’s versionfield might look like: Gem::Specification.new do |s| s.name = hola s.version = 1.0.0.pre Other prerelease version numbers might include 2.0.0.rc1, or 1.5.0.beta.3. It just has to have a letter in it, and you’re set. These gems can then be installed with the --pre flag, like so: Daniel Holth ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
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. I followed these lengthy discussions .. if an agreement was found and was technically sound why do you think people still arguing about that? And were talking years not hours to come up with those peps. Its non-adopted, non-final predecessor turns 8 in April. Unfortunately these kinds of things can be argued endlessly. I like a joke from time to time: python -c print 1.2.dev1 1.2.1 - False Even easier in my unicors populated universe. Ill simply ignore anything about those peps, for what it matters In that case after these last objections are dropped lets accept this PEP. Hooray! You can start generating Metadata 1.3 today with bdist_wheel, and distribute already understands the Provides-Extra: feature used to represent setuptools extras. Description-in-body-section is also trouble-free with no changes to pkg_resources. As a comparison, rubygems says (http://guides.rubygems.org/patterns/#prerelease-gems [1]) Many gem developers have versions of their gem ready to go out for testing or “edge” releases before a big gem release. RubyGems supports the concept of “prerelease” versions, which could be betas, alphas, or anything else that isn’t worthy of a real gem release yet. Taking advantage of this is easy. All you need is one or more letters in the gem version. For example, here’s what a prerelease gemspec’s version field might look like: Gem::Specification.new do |s| s.name [2] = hola s.version = 1.0.0.pre Other prerelease version numbers might include 2.0.0.rc1, or 1.5.0.beta.3. It just has to have a letter in it, and you’re set. These gems can then be installed with the --pre flag, like so: Daniel Holth Links: -- [1] http://guides.rubygems.org/patterns/#prerelease-gems [2] http://s.name ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
On Thu, Feb 7, 2013 at 4:17 AM, a.cava...@cavallinux.eu 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 accidentally download pre-releases. By contrast, starting with PEP 426, alphanumeric pre-releases will be excluded by default (while still allowing users to explicitly request them when necessary). I'll be updating the PEP to include some simpler examples of compliant versioning schemes projects may actually want to use, as well as including more rationale for the complexity of the overall scheme (still not as much as PEP 386, but at least some). The sole current example, which includes *every* feature of the version scheme in a single list is intended as a stress test for metadata processors, rather than as any kind of guide to possible versioning schemes. I now realise this is potentially confusing for users looking for guidance on the kinds of versioning schemes they can use while still remaining within the format defined by the PEP. 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 constrains what is permitted inside version specifiers, this will also serve to permit things like Requires-Python: 2 as a shorthand for Requires-Python: = 2.0, 3 (and similar in Requires-Dist and Setup-Requires-Dist for other projects where major releases may contain backwards incompatible changes, and thus cross-version compatibility should be explicitly indicated with more permissive specifiers like =2.6, =3.2, 4) Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
On Thu, Feb 7, 2013 at 11:50 AM, Donald Stufft donald.stu...@gmail.com 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. Might be there was a particular case they were making sure was rational. Only mentioning here because major only project numbers can get big which reminded me! So long as the numeric component is monotonically increasing, there is no problem with a date-based versioning scheme under PEP 386 or PEP 426. If distutils2 was ruling them out, it was applying an additional constraint not present in the spec. (Date based versioning is actually one of the use cases I intended to include in the next PEP draft - .postN releases are quite handy for that use case, as they make it easy to do hotfix releases while still retaining a purely date-based scheme for the numeric component) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
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 made. My whole point would be: if walks like a duck sounds like a duck *don't call it a plane*. *If a version has to be enforced* it'd better sommething simple as a major.minor[.micro] or an integer or a timestamp for that matter. Something that could be simply sorted without requiring magic handling. 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). BTW Rpm has a version and (as fallback) an Epoch field overriding the version to repair such a problem: not used often these days, but it is there. On Tue 05/02/13 09:08, Ronald Oussoren ronaldousso...@mac.com wrote: On 4 Feb, 2013, at 20:59, Antonio Cavallo a.cav a...@cavallinux.eu 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 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! I'm talking about version numbers in the real world and those just aren't that simple. The scheme described in the PEP is fairly complex, but as Nick mentioned not all features will be used at the same time. The scheme also gives a clear and sane meaning to almost all version numbers actually used on PyPI, please check the archives to see the discussions that led to this PEP. That doesn't mean that the documentation can't nudge users towards a simple major.minor[.micro] scheme, possibly referencing semantic versioning. Ronald ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
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 overall useful number for a version and here's why: Django (for example) maintains older versions for a set period of time, If you do it via timestamps than 1.1.1 which happens to be released after 1.2.0 (because of a security issue or glaring bug) will be considered newer. Handwaving the problem away with a source revision number or timestamp ignores a fundamental property of a version. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
On Tue, Feb 5, 2013 at 7:54 AM, Donald Stufft donald.stu...@gmail.comwrote: 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 overall useful number for a version and here's why: Django (for example) maintains older versions for a set period of time, If you do it via timestamps than 1.1.1 which happens to be released after 1.2.0 (because of a security issue or glaring bug) will be considered newer. Handwaving the problem away with a source revision number or timestamp ignores a fundamental property of a version What pkg_resources does for sorting is to append final for sorting. So the sorting is really just a, b, c, f. This scheme has been important for 8+ years now. PEP 386, from 2009, narrows the allowed versions. Now the salient part of PEP 386 has been incorporated into Metadata 1.3. 1.0.0a0 1.0.0b0 1.0.0c0 ~= 1.0.0rc0 1.0.0 == 1.0.0f 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 many deployments upgraded to an unstable version without realizing it. Once the tools are updated it will be easy to install a beta release with pip if and only if you specifically ask for it. 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 - and + in the version numbers, and package tools would be more likely to have to implement both PEP 386 and semver to work properly. It would result in a minimal amount of win. I can live with the PEP 386 style version numbers and will stick to using Major.Minor.Micro for my projects. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
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 - and + in the version numbers, and package tools would be more likely to have to implement both PEP 386 and semver to work properly. It would result in a minimal amount of win. I can live with the PEP 386 style version numbers and will stick to using Major.Minor.Micro for my projects. To be honest I like semver. But I think it's a large enough break in backwards compatibility that the specific syntax of a semver version doesn't really make much sense to move to. However the semantic part of semver, which in my opinion is the important part, absolutely could be applied to the proposed scheme. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
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 the fact that in your mind 1.2.x comes later than 1.1.x is because you're already sorting them adding a semantic value built into the version *LABEL*. For a counter example how would compare then 1.x and 2.x: is 2.x continuing along 1.x or is it a completely unrelated source? And that *cannot* be captured. My point in suggesting a timestamp is because it freeze the repository state in a unique way: scms have already that concept built into it (even distributed scm have that!). On Tue 05/02/13 13:54, Donald Stufft donald.stu...@gmail.com 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 version must be). Timestamp or reversion number is not overall useful number for a version and here's why: Django (for example) maintains older versions for a set period of time, If you do it via timestamps than 1.1.1 which happens to be released after 1.2.0 (because of a security issue or glaring bug) will be considered newer. Handwaving the problem away with a source revision number or timestamp ignores a fundamental property of a version. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
On Wed, Feb 6, 2013 at 12:15 AM, a.cava...@cavallinux.eu 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 fix one of the two (the branch in this case). BTW the fact that in your mind 1.2.x comes later than 1.1.x is because you're already sorting them adding a semantic value built into the version *LABEL*. For a counter example how would compare then 1.x and 2.x: is 2.x continuing along 1.x or is it a completely unrelated source? And that *cannot* be captured. My point in suggesting a timestamp is because it freeze the repository state in a unique way: scms have already that concept built into it (even distributed scm have that!). 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 inserting an extra period to turn X.YdevN into X.Y.devN). In other words, the intent was not to invent a new versioning scheme, but merely to formalise a subset of one that already existed in the wild. One of the main goals of PEP 426 is to *lower* barriers to adoption for the new metadata standard, not to create new ones - throwing away the work that went into creating the PEP 386 versioning scheme would be a foolish waste of time and energy. Even the problem with the sorting of dev releases was enough to hinder adoption of v1.2 of the metadata - there's no way we're going to try to enforce a more radical shift in the community approaches versioning. We already know the most likely outcome of such an effort: people will simply stick with v1.1 of the metadata scheme and continuing to use the existing packaging tools, as migrating to the new ones would require a whole lot pointless busywork to redesign their build processes and workflows. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
On Tue, Feb 5, 2013 at 3:08 PM, Daniel Holth dho...@gmail.com 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 many deployments upgraded to an unstable version without realizing it. Once the tools are updated it will be easy to install a beta release with pip if and only if you specifically ask for it. May be versioning scheme is trying to take on too much on itself that could possibly be solved elsewhere in a simpler way? Immature software distribution is a requirement that makes perfect sense --but even that is not in the scope of this PEP -- could it better addressed by having a something like Pypi release channels instead ie some separate indexes for unstable/alpha/bleeding edge packages that responsible and consenting adults could use as they please or something similar? This is FWIW a common practice on Debian. -- Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.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
Re: [Distutils] PEP 426, round 733 ;)
On Wed, Feb 6, 2013 at 1:06 AM, Philippe Ombredanne pombreda...@nexb.com wrote: On Tue, Feb 5, 2013 at 3:08 PM, Daniel Holth dho...@gmail.com 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 many deployments upgraded to an unstable version without realizing it. Once the tools are updated it will be easy to install a beta release with pip if and only if you specifically ask for it. May be versioning scheme is trying to take on too much on itself that could possibly be solved elsewhere in a simpler way? Immature software distribution is a requirement that makes perfect sense --but even that is not in the scope of this PEP -- could it better addressed by having a something like Pypi release channels instead ie some separate indexes for unstable/alpha/bleeding edge packages that responsible and consenting adults could use as they please or something similar? This is FWIW a common practice on Debian. That is in no way simpler than telling installation tool developers: Do not install pre-releases, unless a user or developer specifically asks for them. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
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...@gmail.com wrote: On Wed, Feb 6, 2013 at 12:15 AM, a.cav a...@cavallinux.eu 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 fix one of the two (the branch in this case). BTW the fact that in your mind 1.2.x comes later than 1.1.x is because you're already sorting them adding a semantic value built into the version *LABEL*. For a counter example how would compare then 1.x and 2.x: is 2.x continuing along 1.x or is it a completely unrelated source? And that *cannot* be captured. My point in suggesting a timestamp is because it freeze the repository state in a unique way: scms have already that concept built into it (even distributed scm have that!). 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 inserting an extra period to turn X.YdevN into X.Y.devN). In other words, the intent was not to invent a new versioning scheme, but merely to formalise a subset of one that already existed in the wild. One of the main goals of PEP 426 is to *lower* barriers to adoption for the new metadata standard, not to create new ones - throwing away the work that went into creating the PEP 386 versioning scheme would be a foolish waste of time and energy. Even the problem with the sorting of dev releases was enough to hinder adoption of v1.2 of the metadata - there's no way we're going to try to enforce a more radical shift in the community approaches versioning. We already know the most likely outcome of such an effort: people will simply stick with v1.1 of the metadata scheme and continuing to use the existing packaging tools, as migrating to the new ones would require a whole lot pointless busywork to redesign their build processes and workflows. Regards, Nick. -- Nick Coghlan | ncoghlan@g mail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
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/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
On Mon, Feb 4, 2013 at 2:10 PM, Nick Coghlan ncogh...@gmail.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
to metadata v1.1 (PEP 314) or earlier, as those versions do not mandate
a particular versioning scheme.
Suffixes and ordering
-
The following suffixes are the only ones allowed at the given level of the
version hierarchy and they are ordered as listed.
Within a numeric release (``1.0``, ``2.7.3``)::
.devN, aN, bN, cN, rcN, no suffix, .postN
Are we trying to mix in too many thing in a versioning scheme?
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
of versioned components, sorts naturally in most filesystems and tools
and is easy to implement.
With the proposed scheme, I can picture myself having to call some
code each time I need compare two package versions and scratching my
head otherwise.
Having been involved in defining version schemes in the past for
Eclipse, I came then to the conclusion that anything that does not
sort lexicographically is probably a bad idea.
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 | pombreda...@nexb.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
Re: [Distutils] PEP 426, round 733 ;)
On Mon, Feb 4, 2013 at 10:31 AM, Philippe Ombredanne
pombreda...@nexb.comwrote:
On Mon, Feb 4, 2013 at 2:10 PM, Nick Coghlan ncogh...@gmail.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
to metadata v1.1 (PEP 314) or earlier, as those versions do not mandate
a particular versioning scheme.
Suffixes and ordering
-
The following suffixes are the only ones allowed at the given level of
the
version hierarchy and they are ordered as listed.
Within a numeric release (``1.0``, ``2.7.3``)::
.devN, aN, bN, cN, rcN, no suffix, .postN
Are we trying to mix in too many thing in a versioning scheme?
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
of versioned components, sorts naturally in most filesystems and tools
and is easy to implement.
With the proposed scheme, I can picture myself having to call some
code each time I need compare two package versions and scratching my
head otherwise.
Having been involved in defining version schemes in the past for
Eclipse, I came then to the conclusion that anything that does not
sort lexicographically is probably a bad idea.
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)
It's weird, but we need to maintain sort order with
https://bitbucket.org/tarek/distribute/src/tip/pkg_resources.py?at=default#cl-1948for
the subset of version numbers that fit the new regex. This issue has
been discussed at length.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
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 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
Re: [Distutils] PEP 426, round 733 ;)
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
Re: [Distutils] PEP 426, round 733 ;)
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 Coghlanncoghlan@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
Re: [Distutils] PEP 426, round 733 ;)
Nick Coghlan ncoghlan at 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 Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 426, round 733 ;)
On 5 Feb 2013 02:01, 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 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 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
