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" dholth@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
On Thu, Feb 7, 2013 at 4:17 AM,
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 | ncoghlan@gmail.com | Brisbane, Australia
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 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")
Fedora/Firefox really don't have minor version numbers at all? Chrome does have minor (actually way more than that http://d.stufft.io/image/3g0b07221P3l). 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!
On Thu, Feb 7, 2013 at 11:50 AM, Donald Stufft
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 | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
a.cavallo@cavallinux.eu
-
Donald Stufft
-
Nick Coghlan