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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4