[Numpy-discussion] Removing datetime support for 1.4.x series ?
Thu Feb 4 09:17:34 CST 2010
On Thu, Feb 4, 2010 at 3:46 PM, Travis Oliphant <firstname.lastname@example.org> wrote:
> If the issue is having too many releases that are .X releases, then let's
> just slow that down.
The issue is not so much version numbering - I think keeping
compatibility between .X releases is slightly better because that's
the usually followed convention in open source. Since Python itself
does not follow this convention, it does not matter much though.
But we have to keep ABI compatibility for several years between
releases, whatever versions numbering we want to use. I guess my main
concern is that you seem to imply that breaking ABI is necessary to go
forward, whereas I think every maturing library should simply *forbid*
breaking ABI between major releases. As an example, gtk and QT have
been able to keep ABI compatibility for almost a decade, and those are
much more complicated than numpy will ever be. Python itself is going
toward fixing the ABI for at least a subset of the API, so that's
something that the python community will come to expect IMO.
> I just
> never had the opinion that we would *never* change the ABI.
> I don't think there is any disagreement in the general idea that the ABI
> should remain stable for a long time. I think the problem is that in this
> particular instance, we had different opinions about the importance of ABI
> compatibility for the 1.4 release. I did not think it was possible, and
> was surprised when it was attempted.
It is almost always possible to keep ABI compatibility - it is a
tradeoff between maintainability, amount of time we are willing to
> I will help make the 1.3.1 release if this is an agreeable solution. This
> pattern would certainly help create stability while still allowing change to
> happen in a reasonable way.
Maybe we should seriously think about working on a major overhaul of
NumPy to allow changes while keeping ABI compatibility, then. But
after finishing the transition to Py3k - maybe Pauli and Chuck would
have a better idea on the exact path forward w.r.t Py3k transition
More information about the NumPy-Discussion