[Distutils] version scheme: a case for dropping ".devNNN" and ".postNNN"

Tres Seaver tseaver at palladion.com
Fri Jun 12 03:11:38 CEST 2009

Hash: SHA1

Trent Mick wrote:
>>> - when I specify a dependency against a particular build_number of a
>>> package, I don't care if that build_number happened to be a released
>>> version or a dev version
>> However, to specify that dependency you're going to need a way to represent
>> the build number as part of a requirement string, at which point we're right
>> back where we started.
> Perhaps. I'm wondering if the separation of "version" (does not
> include the ".dev") and "build_number" helps clear up some of the
> cases.
> If "1.2.3.dev456"-type version strings don't appear in packages
> released to PyPI, then the job of the downstream RPM/.deb packagers is
> easier (they then don't need to care about the spelling of the version
> with the build number). Have a "RationalReleaseVersion()" that is just
> the non-dev part of the proposal.
> Yes, as you say, the requirement/dependency fields (presumably they
> will be strings) need a way to spell the "build_number" part. However,
> the large set of setup.py authors that don't need to understand or use
> dependency strings don't need to see that.

Assuming that we add the requisite 'build_number' field to PKG_INFO,
could we allow spelling a dependency on a combined version + build
number using an "odd" spelling, such as: '1.2.3#4567' or '1.2.3 at 4567'?
This spelling would be *disallowed* for "released" packages, but could
still satisfy the folks who use such dependencies in internal-only
development mode.

Effectively, my proposal here is to move the whole "build_number" topic
out of the PEP 386 (which is about versioning), and into PEP 345
(whichadds dependencies on distributions to PKG_INFO).

- --
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Distutils-SIG mailing list