[Numpy-discussion] Removing datetime support for 1.4.x series ?

[Charles R Harris]

On Wed, Feb 10, 2010 at 6:22 PM, David Cournapeau <cournape at gmail.com>wrote:

> On Thu, Feb 11, 2010 at 5:31 AM, Travis Oliphant <oliphant at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100210/f291493d/attachment.html>