On Wed, Feb 6, 2013 at 11:37 AM, <a.cavallo@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 version field 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