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

[Charles R Harris]

On Thu, Feb 4, 2010 at 12:11 AM, Travis Oliphant <oliphant at enthought.com>wrote:

>
> On Feb 3, 2010, at 11:58 AM, Robert Kern wrote:
>
> > On Tue, Feb 2, 2010 at 23:45, Travis Oliphant
> > <oliphant at enthought.com> wrote:
> >
> >> I consider ABI a very significant think.  We should be very accurate
> >> about when a re-compile is required.    I just don't believe that we
> >> should be promising ABI compatibility at .X releases.   I never had
> >> that intention.  I don't remember when it crept in to the ethos.
> >
> > Please refer to your(!) message "Report from SciPy" dated 2008-08-23:
> >
> > """
> > Robert K, Chuck H, Stefan VdW, Jarrod M, David C, and I had a nice
> > discussion about the future directions of NumPy.   We resolved some
> > things and would like community feedback on them if there are
> > opinions.
> >
> > * we will be moving to time-based releases (at least 2 times a year --
> > November / May) with major changes not accepted about 4 weeks before
> > the
> > release.
> > * The releases will be numbered major.minor.bugfix
> > * There will be no ABI changes in minor releases
> > * There will be no API changes in bugfix releases
> > """
>
> Ah, yes.  Thanks.  I forgot about that report.   It sounds like we
> haven't broken the ABI since that time then, right?   How often have
> we broken ABI?   If we haven't broken it since that report, then we
> have had a 18 months of ABI stability.   That's a bit different of a
> picture than David is painting.
>
> Here is the situation as I see it:
>    * date-time support can't be added without breaking the ABI.
>    * we have already released a version of NumPy that breaks the ABI
> (i.e. the 'cat is out of the bag')
>
> I think we are all in agreement that we should make a release that has
> ABI compatibility with previous releases but keeps all the other
> changes that it can.
>
> The only question left is what release number to give it:   1.4.1 or
> 1.3.1 or something else?   There are down-sides to any choice we make,
>

1.3.1 would be a bugfix release, 1.4 has new features and 1.4.1 really
*would* be a bug fix release.


> but I would argue that if we choose something like 1.3.1 (or maybe
> 1.3.9) we can promise no ABI breakage in odd releases and use this as
> an "experience" to re-enforce the memory of that commitment.
>
>
That's kludgy. As an example of the problems that come with frequent ABI
changes, I present Python itself. It's a pain to keep up. Note that Guido
has declared "No more", for Python 3.x. The message did reach the top of the
mountain. I say we plan an ABI breaking release and maybe add the extra
space for hasobject at the same time. It seems the time has come to bite
that bullet, but let us do it on purpose.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100204/18cbe91f/attachment.html>