Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[Ralf Gommers]

On Sat, Feb 11, 2012 at 7:51 PM, Travis Oliphant wrote:

> NumPy 1.7 is due out in the next few weeks.


This depends on whether all the issues regarding the move to gcc 4.x on
Windows will be solved. Right now numpy is not releasable. Either those
issues get solved, or we have to do something about the part of datetime
that requires 4.x. Neither seems to be very easy.

Ralf


>   This will obviously support 2.4.   It can be used for as long as people
> want.
>
> Right now, there is a plan for NumPy 1.8 to be released in the summer
> which will have much attention paid to it in order to improve the
> documentation, add bug-fixes, as well as make feature additions.Right
> now, the plan is to have that release support 2.5, however, major bug-fixes
> will be back-ported to the 1.7 series as patches are available.   I suspect
> that different organizations will use different versions of NumPy as their
> own LTS.I plan on encouraging people to use 1.8 as the LTS.
>
> Work on NumPy 2.0 is already underway, but it will likely not be ready
> until January of 2013 at the earliest.   Of course, there may be happy
> circumstances that accelerate that plan and other events that delay it.
>  But, that is my best guess at the moment.
>
> Best,
>
> -Travis
>
>
>
>
>
>
>
> On Feb 10, 2012, at 3:25 AM, David Cournapeau wrote:
>
> > On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers
> >  wrote:
> >>
> >>
> >> On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant 
> wrote:
> >>>
> >>> I think supporting Python 2.5 and above is completely fine.  I'd even
> be
> >>> in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for
> NumPy
> >>> 2.8
> >>>
> >> +1 for dropping Python 2.5 support also for an LTS release. That will
> make
> >> it a lot easier to use str.format() and the with statement (plus many
> other
> >> things) going forward, without having to think about if your changes
> can be
> >> backported to that LTS release.
> >
> > At the risk of sounding like a broken record, I would really like to
> > stay to 2.4, especially for a long term release :) This is still the
> > basis used by a lots of long-term python products. If we can support
> > 2.4 for a LTS, I would then be much more comfortable to allow bumping
> > to 2.5 for 1.8.
> >
> > David
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[Travis Oliphant]

NumPy 1.7 is due out in the next few weeks.   This will obviously support 2.4.  
 It can be used for as long as people want. 

Right now, there is a plan for NumPy 1.8 to be released in the summer which 
will have much attention paid to it in order to improve the documentation, add 
bug-fixes, as well as make feature additions.Right now, the plan is to have 
that release support 2.5, however, major bug-fixes will be back-ported to the 
1.7 series as patches are available.   I suspect that different organizations 
will use different versions of NumPy as their own LTS.I plan on encouraging 
people to use 1.8 as the LTS. 

Work on NumPy 2.0 is already underway, but it will likely not be ready until 
January of 2013 at the earliest.   Of course, there may be happy circumstances 
that accelerate that plan and other events that delay it.  But, that is my best 
guess at the moment. 

Best, 

-Travis







On Feb 10, 2012, at 3:25 AM, David Cournapeau wrote:

> On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers
>  wrote:
>> 
>> 
>> On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant  wrote:
>>> 
>>> I think supporting Python 2.5 and above is completely fine.  I'd even be
>>> in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for NumPy
>>> 2.8
>>> 
>> +1 for dropping Python 2.5 support also for an LTS release. That will make
>> it a lot easier to use str.format() and the with statement (plus many other
>> things) going forward, without having to think about if your changes can be
>> backported to that LTS release.
> 
> At the risk of sounding like a broken record, I would really like to
> stay to 2.4, especially for a long term release :) This is still the
> basis used by a lots of long-term python products. If we can support
> 2.4 for a LTS, I would then be much more comfortable to allow bumping
> to 2.5 for 1.8.
> 
> David
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[Ralf Gommers]

On Sat, Feb 11, 2012 at 4:08 PM, David Cournapeau wrote:

> On Sat, Feb 11, 2012 at 1:30 PM, Ralf Gommers
>  wrote:
> >
> >
> > As Bruce said, 29 Feb 2012 and not 2014:
> > https://access.redhat.com/support/policy/updates/errata/
>
> I think Bruce and me were not talking about the same RHEL version (4 vs 5).
>
> Ah, in that case it makes more sense to keep supporting it for two more
years.

Let me see if I can set up a buildbot for 2.4.
>

That would be very helpful, thanks.

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[David Cournapeau]

On Sat, Feb 11, 2012 at 1:30 PM, Ralf Gommers
 wrote:
>
>
> As Bruce said, 29 Feb 2012 and not 2014:
> https://access.redhat.com/support/policy/updates/errata/

I think Bruce and me were not talking about the same RHEL version (4 vs 5).

Let me see if I can set up a buildbot for 2.4.

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[Ralf Gommers]

On Sat, Feb 11, 2012 at 12:05 PM, David Cournapeau wrote:

> On Sat, Feb 11, 2012 at 9:08 AM, Ralf Gommers
>  wrote:
> >
> >
> > On Fri, Feb 10, 2012 at 8:51 PM, Ralf Gommers <
> ralf.gomm...@googlemail.com>
> > wrote:
> >>
> >>
> >>
> >> On Fri, Feb 10, 2012 at 10:25 AM, David Cournapeau 
> >> wrote:
> >>>
> >>> On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers
> >>>  wrote:
> >>> >
> >>> >
> >>> > On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant  >
> >>> > wrote:
> >>> >>
> >>> >> I think supporting Python 2.5 and above is completely fine.  I'd
> even
> >>> >> be
> >>> >> in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for
> >>> >> NumPy
> >>> >> 2.8
> >>> >>
> >>> > +1 for dropping Python 2.5 support also for an LTS release. That will
> >>> > make
> >>> > it a lot easier to use str.format() and the with statement (plus many
> >>> > other
> >>> > things) going forward, without having to think about if your changes
> >>> > can be
> >>> > backported to that LTS release.
> >>>
> >>> At the risk of sounding like a broken record, I would really like to
> >>> stay to 2.4, especially for a long term release :) This is still the
> >>> basis used by a lots of long-term python products. If we can support
> >>> 2.4 for a LTS, I would then be much more comfortable to allow bumping
> >>> to 2.5 for 1.8.
> >>
> >>
> >> At the very least someone should step up to do the testing or maintain a
> >> buildbot for Python 2.4 then. Also for scipy, assuming that scipy keeps
> >> supporting the same Python versions as numpy.
> >>
> > Here's a list of Python requirements for other important scientific
> python
> > projects:
> > - ipython: >= 2.6
> > - matplotlib: v1.1 supports 2.4-2.7, v1.2 will support >= 2.6
> > - scikit-learn: >= 2.6
> > - scikit-image: >= 2.5
> > - scikits.statsmodels: >= 2.5 (next release probably >= 2.6)
> >
> > That there are still some projects/products out there that still use
> Python
> > 2.4 (some examples of such products would be nice by the way) is not
> enough
> > of a reason by itself to continue to support it in new releases. There
> has
> > to be a good reason for those products to require the very latest numpy,
> > even though they are fine with a very old Python and older versions of
> > almost any other Python package.
>
> I don't think that last argument is relevant for a LTS.


I think it's a relevant argument right now, irrespective of whether or not
1.7 will be an LTS.


> Numpy is used in environments where you cannot easily control what's
> installed. RHEL
> still uses python 2.4 and will be supported until 2014 in the
> production phase.
>

As Bruce said, 29 Feb 2012 and not 2014:
https://access.redhat.com/support/policy/updates/errata/

Ralf

As for projects still using python 2.4, using the most downloaded
> packages from this list
> http://taichino.appspot.com/pypi_ranking/modules?page=1, most of them
> supported python 2.4 or below. lxml, zc.buildout, setuptools, pip,
> virtualenv and sqlalchemy do. Numpy itself is also used outside the
> strict scientific realm, which is why I am a bit warry about just
> comparing with other scientific python packages.
>
> Now, if everybody else is against it, I don't want to be a pain about
> it either :)
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[David Cournapeau]

On Sat, Feb 11, 2012 at 9:08 AM, Ralf Gommers
 wrote:
>
>
> On Fri, Feb 10, 2012 at 8:51 PM, Ralf Gommers 
> wrote:
>>
>>
>>
>> On Fri, Feb 10, 2012 at 10:25 AM, David Cournapeau 
>> wrote:
>>>
>>> On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers
>>>  wrote:
>>> >
>>> >
>>> > On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant 
>>> > wrote:
>>> >>
>>> >> I think supporting Python 2.5 and above is completely fine.  I'd even
>>> >> be
>>> >> in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for
>>> >> NumPy
>>> >> 2.8
>>> >>
>>> > +1 for dropping Python 2.5 support also for an LTS release. That will
>>> > make
>>> > it a lot easier to use str.format() and the with statement (plus many
>>> > other
>>> > things) going forward, without having to think about if your changes
>>> > can be
>>> > backported to that LTS release.
>>>
>>> At the risk of sounding like a broken record, I would really like to
>>> stay to 2.4, especially for a long term release :) This is still the
>>> basis used by a lots of long-term python products. If we can support
>>> 2.4 for a LTS, I would then be much more comfortable to allow bumping
>>> to 2.5 for 1.8.
>>
>>
>> At the very least someone should step up to do the testing or maintain a
>> buildbot for Python 2.4 then. Also for scipy, assuming that scipy keeps
>> supporting the same Python versions as numpy.
>>
> Here's a list of Python requirements for other important scientific python
> projects:
> - ipython: >= 2.6
> - matplotlib: v1.1 supports 2.4-2.7, v1.2 will support >= 2.6
> - scikit-learn: >= 2.6
> - scikit-image: >= 2.5
> - scikits.statsmodels: >= 2.5 (next release probably >= 2.6)
>
> That there are still some projects/products out there that still use Python
> 2.4 (some examples of such products would be nice by the way) is not enough
> of a reason by itself to continue to support it in new releases. There has
> to be a good reason for those products to require the very latest numpy,
> even though they are fine with a very old Python and older versions of
> almost any other Python package.

I don't think that last argument is relevant for a LTS. Numpy is used
in environments where you cannot easily control what's installed. RHEL
still uses python 2.4 and will be supported until 2014 in the
production phase.

As for projects still using python 2.4, using the most downloaded
packages from this list
http://taichino.appspot.com/pypi_ranking/modules?page=1, most of them
supported python 2.4 or below. lxml, zc.buildout, setuptools, pip,
virtualenv and sqlalchemy do. Numpy itself is also used outside the
strict scientific realm, which is why I am a bit warry about just
comparing with other scientific python packages.

Now, if everybody else is against it, I don't want to be a pain about
it either :)

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[Ralf Gommers]

On Fri, Feb 10, 2012 at 8:51 PM, Ralf Gommers
wrote:

>
>
> On Fri, Feb 10, 2012 at 10:25 AM, David Cournapeau wrote:
>
>> On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers
>>  wrote:
>> >
>> >
>> > On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant 
>> wrote:
>> >>
>> >> I think supporting Python 2.5 and above is completely fine.  I'd even
>> be
>> >> in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for
>> NumPy
>> >> 2.8
>> >>
>> > +1 for dropping Python 2.5 support also for an LTS release. That will
>> make
>> > it a lot easier to use str.format() and the with statement (plus many
>> other
>> > things) going forward, without having to think about if your changes
>> can be
>> > backported to that LTS release.
>>
>> At the risk of sounding like a broken record, I would really like to
>> stay to 2.4, especially for a long term release :) This is still the
>> basis used by a lots of long-term python products. If we can support
>> 2.4 for a LTS, I would then be much more comfortable to allow bumping
>> to 2.5 for 1.8.
>>
>
> At the very least someone should step up to do the testing or maintain a
> buildbot for Python 2.4 then. Also for scipy, assuming that scipy keeps
> supporting the same Python versions as numpy.
>
> Here's a list of Python requirements for other important scientific python
projects:
- ipython: >= 2.6
- matplotlib: v1.1 supports 2.4-2.7, v1.2 will support >= 2.6
- scikit-learn: >= 2.6
- scikit-image: >= 2.5
- scikits.statsmodels: >= 2.5 (next release probably >= 2.6)

That there are still some projects/products out there that still use Python
2.4 (some examples of such products would be nice by the way) is not enough
of a reason by itself to continue to support it in new releases. There has
to be a good reason for those products to require the very latest numpy,
even though they are fine with a very old Python and older versions of
almost any other Python package.

It would also make sense to ship binaries (for Windows at least) of all
Python versions we say we support. We haven't done so for 2.4 for a very
long time.

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[Ralf Gommers]

On Fri, Feb 10, 2012 at 10:25 AM, David Cournapeau wrote:

> On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers
>  wrote:
> >
> >
> > On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant 
> wrote:
> >>
> >> I think supporting Python 2.5 and above is completely fine.  I'd even be
> >> in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for
> NumPy
> >> 2.8
> >>
> > +1 for dropping Python 2.5 support also for an LTS release. That will
> make
> > it a lot easier to use str.format() and the with statement (plus many
> other
> > things) going forward, without having to think about if your changes can
> be
> > backported to that LTS release.
>
> At the risk of sounding like a broken record, I would really like to
> stay to 2.4, especially for a long term release :) This is still the
> basis used by a lots of long-term python products. If we can support
> 2.4 for a LTS, I would then be much more comfortable to allow bumping
> to 2.5 for 1.8.
>

At the very least someone should step up to do the testing or maintain a
buildbot for Python 2.4 then. Also for scipy, assuming that scipy keeps
supporting the same Python versions as numpy.

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[mark florisson]

On 5 February 2012 07:19, Ralf Gommers  wrote:
>
>
> On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant  wrote:
>>
>> I think supporting Python 2.5 and above is completely fine.  I'd even be
>> in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for NumPy
>> 2.8
>>
> +1 for dropping Python 2.5 support also for an LTS release. That will make
> it a lot easier to use str.format() and the with statement (plus many other
> things) going forward, without having to think about if your changes can be
> backported to that LTS release.

The with statement works just fine in python 2.5, all you have to do
is 'from __future__ import with_statement'. As for str.format, well...

> Ralf
>
>>
>>
>>
>> On Feb 4, 2012, at 10:13 PM, Bruce Southey wrote:
>>
>> > On Sat, Feb 4, 2012 at 6:07 PM, Charles R Harris
>> >  wrote:
>> >>
>> >>
>> >> On Sat, Feb 4, 2012 at 3:03 PM, Travis Oliphant 
>> >> wrote:
>> >>>
>> >>> We are spending a lot of time on NumPy and will be for the next few
>> >>> months.  I think that 1.8 will be a better long term release.  We need
>> >>> a few
>> >>> more fundamental features yet.
>> >>>
>> >>> Look for a roadmap document for discussion from Mark Wiebe and I
>> >>> within
>> >>> the week about NumPy 1.8 which has a target release of June 2012.
>> >>>
>> >>
>> >> Looking forward to that document.
>> >>
>> >> Chuck
>> >>
>> >> ___
>> >> NumPy-Discussion mailing list
>> >> NumPy-Discussion@scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>> >>
>> >
>> > A suitable long term release would include deprecating old macros,
>> > datetime and einsum. While I would like to include NA, I am rather
>> > concerned with the recent bugs that have been uncovered with it. So I
>> > am rather wary of having to forced to backport fixes simply because
>> > someone said we would "support with bug fixes for the next 2-3 years".
>> > Rather at least clearly indicate that not every fix will be
>> > backported.
>> >
>> > I propose that we use this opportunity end support for Python 2.4
>> > especially since Red Hat Enterprise Linux (RHEL) 4 is February 29th,
>> > 2012. According to SourceForge, the last available binary release for
>> > Python 2.4 was for numpy 1.2.1 (released 2008-10-29). There is still
>> > quite a few downloads (3769) of the Python 2.5 numpy 1,6.1 binary.
>> >
>> > Bruce
>> > ___
>> > NumPy-Discussion mailing list
>> > NumPy-Discussion@scipy.org
>> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[David Cournapeau]

On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers
 wrote:
>
>
> On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant  wrote:
>>
>> I think supporting Python 2.5 and above is completely fine.  I'd even be
>> in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for NumPy
>> 2.8
>>
> +1 for dropping Python 2.5 support also for an LTS release. That will make
> it a lot easier to use str.format() and the with statement (plus many other
> things) going forward, without having to think about if your changes can be
> backported to that LTS release.

At the risk of sounding like a broken record, I would really like to
stay to 2.4, especially for a long term release :) This is still the
basis used by a lots of long-term python products. If we can support
2.4 for a LTS, I would then be much more comfortable to allow bumping
to 2.5 for 1.8.

David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[Ralf Gommers]

On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant  wrote:

> I think supporting Python 2.5 and above is completely fine.  I'd even be
> in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for NumPy
> 2.8
>
> +1 for dropping Python 2.5 support also for an LTS release. That will make
it a lot easier to use str.format() and the with statement (plus many other
things) going forward, without having to think about if your changes can be
backported to that LTS release.

Ralf


>
>
> On Feb 4, 2012, at 10:13 PM, Bruce Southey wrote:
>
> > On Sat, Feb 4, 2012 at 6:07 PM, Charles R Harris
> >  wrote:
> >>
> >>
> >> On Sat, Feb 4, 2012 at 3:03 PM, Travis Oliphant 
> wrote:
> >>>
> >>> We are spending a lot of time on NumPy and will be for the next few
> >>> months.  I think that 1.8 will be a better long term release.  We need
> a few
> >>> more fundamental features yet.
> >>>
> >>> Look for a roadmap document for discussion from Mark Wiebe and I within
> >>> the week about NumPy 1.8 which has a target release of June 2012.
> >>>
> >>
> >> Looking forward to that document.
> >>
> >> Chuck
> >>
> >> ___
> >> NumPy-Discussion mailing list
> >> NumPy-Discussion@scipy.org
> >> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >>
> >
> > A suitable long term release would include deprecating old macros,
> > datetime and einsum. While I would like to include NA, I am rather
> > concerned with the recent bugs that have been uncovered with it. So I
> > am rather wary of having to forced to backport fixes simply because
> > someone said we would "support with bug fixes for the next 2-3 years".
> > Rather at least clearly indicate that not every fix will be
> > backported.
> >
> > I propose that we use this opportunity end support for Python 2.4
> > especially since Red Hat Enterprise Linux (RHEL) 4 is February 29th,
> > 2012. According to SourceForge, the last available binary release for
> > Python 2.4 was for numpy 1.2.1 (released 2008-10-29). There is still
> > quite a few downloads (3769) of the Python 2.5 numpy 1,6.1 binary.
> >
> > Bruce
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[Travis Oliphant]

I think supporting Python 2.5 and above is completely fine.  I'd even be in 
favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for NumPy 2.8

-Travis



On Feb 4, 2012, at 10:13 PM, Bruce Southey wrote:

> On Sat, Feb 4, 2012 at 6:07 PM, Charles R Harris
>  wrote:
>> 
>> 
>> On Sat, Feb 4, 2012 at 3:03 PM, Travis Oliphant  wrote:
>>> 
>>> We are spending a lot of time on NumPy and will be for the next few
>>> months.  I think that 1.8 will be a better long term release.  We need a few
>>> more fundamental features yet.
>>> 
>>> Look for a roadmap document for discussion from Mark Wiebe and I within
>>> the week about NumPy 1.8 which has a target release of June 2012.
>>> 
>> 
>> Looking forward to that document.
>> 
>> Chuck
>> 
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>> 
> 
> A suitable long term release would include deprecating old macros,
> datetime and einsum. While I would like to include NA, I am rather
> concerned with the recent bugs that have been uncovered with it. So I
> am rather wary of having to forced to backport fixes simply because
> someone said we would "support with bug fixes for the next 2-3 years".
> Rather at least clearly indicate that not every fix will be
> backported.
> 
> I propose that we use this opportunity end support for Python 2.4
> especially since Red Hat Enterprise Linux (RHEL) 4 is February 29th,
> 2012. According to SourceForge, the last available binary release for
> Python 2.4 was for numpy 1.2.1 (released 2008-10-29). There is still
> quite a few downloads (3769) of the Python 2.5 numpy 1,6.1 binary.
> 
> Bruce
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[Bruce Southey]

On Sat, Feb 4, 2012 at 6:07 PM, Charles R Harris
 wrote:
>
>
> On Sat, Feb 4, 2012 at 3:03 PM, Travis Oliphant  wrote:
>>
>> We are spending a lot of time on NumPy and will be for the next few
>> months.  I think that 1.8 will be a better long term release.  We need a few
>> more fundamental features yet.
>>
>> Look for a roadmap document for discussion from Mark Wiebe and I within
>> the week about NumPy 1.8 which has a target release of June 2012.
>>
>
> Looking forward to that document.
>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

A suitable long term release would include deprecating old macros,
datetime and einsum. While I would like to include NA, I am rather
concerned with the recent bugs that have been uncovered with it. So I
am rather wary of having to forced to backport fixes simply because
someone said we would "support with bug fixes for the next 2-3 years".
Rather at least clearly indicate that not every fix will be
backported.

I propose that we use this opportunity end support for Python 2.4
especially since Red Hat Enterprise Linux (RHEL) 4 is February 29th,
2012. According to SourceForge, the last available binary release for
Python 2.4 was for numpy 1.2.1 (released 2008-10-29). There is still
quite a few downloads (3769) of the Python 2.5 numpy 1,6.1 binary.

Bruce
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[Charles R Harris]

On Sat, Feb 4, 2012 at 3:03 PM, Travis Oliphant  wrote:

> We are spending a lot of time on NumPy and will be for the next few
> months.  I think that 1.8 will be a better long term release.  We need a
> few more fundamental features yet.
>
> Look for a roadmap document for discussion from Mark Wiebe and I within
> the week about NumPy 1.8 which has a target release of June 2012.
>
>
Looking forward to that document.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

[Travis Oliphant]

We are spending a lot of time on NumPy and will be for the next few months.  I 
think that 1.8 will be a better long term release.  We need a few more 
fundamental features yet.  

Look for a roadmap document for discussion from Mark Wiebe and I within the 
week about NumPy 1.8 which has a target release of June 2012.

Thanks,

Travis 


--
Travis Oliphant
(on a mobile)
512-826-7480


On Feb 4, 2012, at 11:37 AM, Charles R Harris  wrote:

> Hi All,
> 
> In the discussion on deprecating old macros in 1.7 as part of pull request 
> 189  the issue of how to move numpy forward and start clearing the decks of 
> accumulated cruft arose. The proposal here is to make the 1.7 a long term 
> support release that we support with bug fixes for the next 2-3 years, and 
> start removing stuff in 1.8 and bump the Python version up to 2.6 (2.7?). The 
> 1.7 release has NA, datetime, and einsum, and I think that is enough to keep 
> folks happy for a while. I don't know what other major features might be on 
> the horizon (labeled arrays?), but 1.7 looks like a good resting place to me.
> 
> Thoughts?
> 
> Chuck 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] On making Numpy 1.7 a long term support release.

[Charles R Harris]

Hi All,

In the discussion on deprecating old macros in 1.7 as part of pull request
189   the issue of how to move
numpy forward and start clearing the decks of accumulated cruft arose. The
proposal here is to make the 1.7 a long term support release that we
support with bug fixes for the next 2-3 years, and start removing stuff in
1.8 and bump the Python version up to 2.6 (2.7?). The 1.7 release has NA,
datetime, and einsum, and I think that is enough to keep folks happy for a
while. I don't know what other major features might be on the horizon
(labeled arrays?), but 1.7 looks like a good resting place to me.

Thoughts?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion