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

[Trent Mick]

>> I.e. Have the shorter "N.N.N[(a|b|c)N]" scheme for "version" to be
>> used for "released" packages. And have a separate field (or fields)
>> for use in dependency handling of unreleased versions? Putting the two
>> together is resulting in package uploads to PyPI
>
> What would be the difference then with the initial proposal ? You
> would end up merging the "short" version
> with the dev field to be able to sort different versions of the same
> distribution.
>
> If we have dev versions, we have to include them in the scheme

I've been thinking from the p.o.v. of what releases get up on PyPI....
and I gather that those releases are the ones that lead to potential
packaging in RPM and .deb repositories.

Say "version" and "build_number" (or whatever name for the latter) are
separate fields. Only "version" is used for putting in package names
(sdist, bdist_*). However the setup() fields for dependency info can
specify checks against both version and build_number.

The difference with the initial proposal (if I'm not missing something) is that:

- packages looking like "foo-1.2.3.dev-r456.tar.gz" don't get uploaded
to PyPI (yeah!)
- the meta data in my released version can still state what SCC
revision (in the build_number field) it was built against
- 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


Trent

-- 
Trent Mick
trentm at gmail.com