On Wed, Feb 10, 2010 at 6:22 PM, David Cournapeau <courn...@gmail.com>wrote:
> 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). > > Nice summary. Here's a link<http://netevil.org/blog/2006/dec/coding-for-coders-api-and-abi-considerations-in-an-evolving-code-base>I posted in 2008 with some observations on ABI and API. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
