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

[David Cournapeau]

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).

cheers,

David