[Distutils] PEP 376 -- support for release versions?

[Robert Kern]

On 2009-11-05 15:03 PM, Tarek Ziadé wrote:
> On Thu, Nov 5, 2009 at 9:31 PM, Sridhar Ratnakumar
> <sridharr at activestate.com>  wrote:
>> Hi,
>>
>> While reading the PEP I noticed that there seems to be no straightforward to
>> specify the package release versions.
>>
>>   >>>  egginfo_dirname('python-ldap', '2.3.10')
>>   'python_ldap-2.3.10.egg-info'
>>
>> Consider the following PyPM package file name:
>>
>>   python-ldap-2.3.10_linux-x86_2.6_2.pypm
>>
>> Here 2.3.10 is python-ldap's version, 2.6 is the Python version .. and 2
>> (the last component) is the binary release number (for ActiveState
>> repository). This is to upgrade previous releases of the same python-ldap
>> (say, python-ldap-2.3.10_linux-x86_2.6_1.pypm).
>
> If I understand correctly, ActiveState has its own releases of
> python-ldap repackaged in pypm files,
> and has several releases per python-ldap versions.
>
> So, why it doesn't have its own versions ? like: 2.3.10.2 in that
> case. (following a PEP 386-compatible scheme)
>
> So this would be:
>
>>>> egginfo_dirname('python-ldap', '2.3.10.2')
> 'python_ldap-2.3.10.2.egg-info'

Generally speaking, it is desirable to distinguish between the upstream 
package's version and the build number rather than munging them together. You 
never know when the upstream package will decide that they need to make a really 
quick bugfix release and just append ".1". The main package version is and 
should remain entirely under the control of the upstream developers, not the 
binary packagers. However, the binary packagers need a place to mark revisions 
of the binary packages distinct from the upstream sources.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco