On Thu, Feb 11, 2010 at 5:31 AM, Travis Oliphant <oliph...@enthought.com> wrote:
> Christopher's argument that having a NumPy 2.0 sets expectations for keeping > 1.4 and 2.0 is a strong one in my mind. The policy of coupling ABI and > version numbers makes less and less sense to me as I hear the concerns of > keeping the ABI consistent. We should be free to change the version > numbers without implying an ABI break. I can only envision right now > perhaps one more ABI break (the one David has talked about to make pimpl > interfaces). I think one issue with versions is that they convey multiple things at the same time. The number itself conveys an idea of "progress" and "features" - the bigger the change in the number, the bigger changes are expected by users. This is the part where everyone has an opinion. Then, there is also the idea that for a library, versions conveys ABI and API compatibility, and this should be purely technical IMO. There are well established rules here: http://www.linuxshowcase.org/2000/2000papers/papers/browndavid/browndavid_html/ """ A major release is an incompatible change to the system software, and implies that [some] applications dependent on the earlier major release (specifically those that relied upon the specific features that have changed incompatibly) will need to be changed in order to work on the new major release. A minor release of the system software is an upward-compatible change--one which adds some new interfaces, but maintains compatibility for all existing interfaces. Applications (or other software products) dependent on an earlier minor release will not need to be changed in order to work on the new minor release: Since the later release contains all the earlier interfaces, the change(s) imparted to the system does not affect those applications. A micro release is a compatible change which does not add any new interfaces: A change is made to the implementation (such as to improve performance, scalability or some other qualitative property) but provides an interface equivalent to all other micro revisions at the same minor level. Again, dependent applications (or other software products) will not need to be changed in order to work on that release as the change imparted to the system (or library) does not undermine their dependencies. """ This idea is ingrained in the tool (the loader use those rules to decide which shared library to load for a given binary with its libraries dependencies). Now, python itself does not follow this rule: ABI and API breaks arrive together (every minor release), but it is my impression that they intend to be stricter for the 3.x series. I have dived into gtk development quite a bit to look at existing processes: Gtk has a good history in that aspect, and is used by a lot of ISV outside open source (vmware, adobe, etc...). They have an experience we don't have. Coincidentally, they are discussing for gtk 3.0 about the best way to go forward, and they have the exact same issue about lack of implementation hiding for structures. For example in there: http://micke.hallendal.net/blog/gtk-30-enabling-incrementalism/, Havoc Pennington (one of the main gtk developer) makes the argument about 3.0 breaking ABI only without any new feature, serving as a basis for new features afterwise, to avoid having a version in preparation taking too long. Maybe that's an idea to follow. Concerning the fear raised by Pauli and others about the massive breakage, I am also looking at existing refactoring tools in C to make this almost automatic (mozilla has developed an impressive set of tools in that area, for example pork: https://developer.mozilla.org/En/Pork_Tools). cheers, David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion