On Wed, Feb 6, 2013 at 11:37 AM, <[email protected]> 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 - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
