[Distutils] distutils version numbering

[M.-A. Lemburg]

Thomas Heller wrote:
>>>>>However, distutils.__version__ for python 2.2
>>>>>as well as python 2.3 are the same ('1.0.3') !
>>>>>Am I just looking in the wrong place ?
>>>>
>>>>No, there was no distutils release after 1.0.3.
>>>>Starting with Python 2.4, distutils seem to follow
>>>>the Python version number (even though I'm not really
>>>>sure who made that decision and what the motivation
>>>>was).
> 
> 
>>>That was me, and it seemed a sensible thing to do.  And not changing
>>>the distutils version number in Python 2.3 was a mistake, imo.
>>
>>Indeed. The version number should change with each new release
>>being made available - whether as stand-alone version or
>>as part of a Python release.
>>
>>I'm not sure whether using the Python version number is
>>correct, though. distutils is not developed at the same
>>pace as Python and a step from Python 2.3 to 2.4 is not
>>necessarily a major step in distutils development.
>>
>>On the other hand, not bumping the version number
>>for API changes is bad as well.
>>
>>I think we ought to keep things separate to make development
>>easier: if you make an API change in distutils, bump the
>>version number. That's a lot easier than remembering to
>>adjust the version string for each Python release.
>>
>>What do you think ?
> 
> For me, the exact value of the version number is pretty meaningless,
> even more if distutils is not developed separately from Python. 

I have to disagree here: distutils *is* developed independent
from the Python core, e.g. we keep Python 2.1 compatibility
where Python core always tries to use the latest and greatest
new feature of the language in the standard lib (not necessarily
making things better, IMHO, but that's a different issue).

The fact that we haven't had any stand-alone releases for
quite a while does not mean that distutils is bound to
the Python release cycle.

> So, 2.4
> means 'the distutils included with Python 2.4'.  Easier to remember that
> distutils 1.0.4 was the version released with 2.4.
> 
> If it makes sense, I can take the resposibility to increase the version
> number with each release, and update the corresponding PEPs, but I won't
> object to the 'change API, bump version number' scheme as well.

If you want to stick with the Python version, you might as well
replace __version__ in distutils/__init__.py with sys.version[:5].
However, this breaks badly if you want to install a stand-alone
version of distutils in a previous version of Python or another
variant of Python such as IronPython, Jython, etc.

distutils still is very much an independent piece of software
which only happens to be shipped together with core Python.
I would rather like to see it stay that way to make life
easier for the developers of Python add-ons, so my vote is
for the standard "change API, bump version number" scheme.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 06 2005)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::