[Python-Dev] Python version numbers and mac OS X

[Jack Jansen]

There's a question of general interest at the very bottom of this
message (that satrted out as a braindump to explain MaxOSX version
numbers).

Recently, "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> said:
> > Sharing is the answer.
> ...
> > This is probably the crux of your reasoning, and I think I
> > disagree. For one, MacOSX (ok, OpenStep is where they got it from)
> > is the first unix-based system that I'm aware of that seems to have
> > a solution to the versioning problem.
> 
> I'm a bit sceptical to any claim that the software versioning problem
> is "solved"; experience tells me it isn't.

Agreed. But they've taken a number of steps that make me think that
for Python they have the exact right solution. Here's how it works.

They have two version numbers, the major and the minor. I say "number"
here, but the major number is actually an arbitrary string and the
minor number is a set of dotted numbers.

The major number is expected to change everytime you make an
incompatible change to your API (remove a routine, add a parameter to
an existing routine, change a structure), exactly like the
PYTHON_API_VERSION number. This number is encoded in the pathname of the
dynamic library, which is something like
/Library/Frameworks/Python.framework/Versions/1011/library.

When you link you actually link against .../Versions/Current/library,
and Current is a symlink to 1011. What is recorded in the binary is
the real pathname, so at runtime a library with major incompatibility
simply won't be found. And if you (the user) want to keep older
versions around that's fine too.

The minor version number is encoded in the library itself, and should
change everytime a compatible change to the API is made (adding a
routine, that sort of thing). Each library has an "oldest minor vesion
number" and a "current minor version number". When you link the
current number of the library is recorded in your application. When
you run the number in your application should be in the range
oldest..current of the library and you're fine.

All that said there's still one thing that breaks for Python, and that
is that it really has two distinct version numbers, the
PYTHON_API_VERSION and the "real" version (2.2).

Plugins are really only interested in the API version, but scripts
that use Python (or programs that embed it) are really only interested
in the real version number.

Programs that both embed and extend Python, such as Zope, are really a
pain because they're interested in both. Although this isn't as hard
as it seems, because in increment of the API version by definition
means an increment in the real version.

I don't have a solution for this yet, mainly because the incrementing
of the API version number hasn't always been completely fair to the
last iota and tittle. For instance, the change of the list.append()
semantics should really have incremented the API version number, but I
don't think it did.

If we could be sure that a newer Python core shared library could work
together with an older Python Lib directory (as long as the API
versions matched) and would provide at least the functionality of that
older Python version we would be fine: use the API version number in
the pathname and use the real version number in the lib/python2.2 and
such. 

Hmm, count this as a request, I guess.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm