matplotlib-devel

[matplotlib-devel] Closing in on 1.3.0 release candidate

[Michael D. <md...@st...>]

The 1.3.0 release candidate tagging is scheduled for this coming Monday, 
May 27.  Unfortunately, due to an oversight on my part, I forgot that is 
a holiday, so I'm going to postpone it one day to Tuesday, May 28.  I 
will be hoping to tag the release by 23:00 UTC that day.

I think we're in really good shape for this release, given all of the 
great work solving and triaging bugs that's been going on since the 
feature freeze.

I think all of the blocker bugs (except possibly #2061) are really close 
to being resolved.  There are a number of issues tagged for 1.3.x that 
may unfortunately need to get punted, but not a very large number.

Question: Should I create a 1.3.x branch now?  The upside of doing that 
is that development of post-1.3.x things can continue on master until 
Tuesday, of course, and I think the pool of 1.3.x things is small enough 
for that to make sense.  The downside, of course, is that any existing 
pull requests against master will have to be manually merged to 1.3.x.  
That shouldn't be a big deal, though, because we don't have too many of 
them left and I can just pull the PR logs when I'm back at the office on 
Tuesday to find out which ones need to be merged.  Any objections to 
creating the branch now?

Mike

Re: [matplotlib-devel] Closing in on 1.3.0 release candidate

[Michael D. <md...@st...>]

I've gone ahead and created the 1.3.x branch on master.  This means that 
the feature freeze on master is effectively lifted.  Any PRs for 1.3.x 
should be milestoned as such before merging (and can be merged to either 
master or the 1.3.x branch).  That milestone will indicate to me what 
needs to be on the v1.3.x branch before making the release candidate 
early next week.

Mike

On 05/24/2013 01:38 PM, Michael Droettboom wrote:
> The 1.3.0 release candidate tagging is scheduled for this coming Monday,
> May 27.  Unfortunately, due to an oversight on my part, I forgot that is
> a holiday, so I'm going to postpone it one day to Tuesday, May 28.  I
> will be hoping to tag the release by 23:00 UTC that day.
>
> I think we're in really good shape for this release, given all of the
> great work solving and triaging bugs that's been going on since the
> feature freeze.
>
> I think all of the blocker bugs (except possibly #2061) are really close
> to being resolved.  There are a number of issues tagged for 1.3.x that
> may unfortunately need to get punted, but not a very large number.
>
> Question: Should I create a 1.3.x branch now?  The upside of doing that
> is that development of post-1.3.x things can continue on master until
> Tuesday, of course, and I think the pool of 1.3.x things is small enough
> for that to make sense.  The downside, of course, is that any existing
> pull requests against master will have to be manually merged to 1.3.x.
> That shouldn't be a big deal, though, because we don't have too many of
> them left and I can just pull the PR logs when I'm back at the office on
> Tuesday to find out which ones need to be merged.  Any objections to
> creating the branch now?
>
> Mike
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Closing in on 1.3.0 release candidate

[Michael D. <md...@st...>]

I am going to hold off one more day on making the release candidate.  
There are three blocker bugs that were discovered over the weekend and 
I'd like to give them a chance for review first:

#854 and #2061: These both have to do with problems with ignoring limits 
and can be fixed by the same changes

#2070: Incorrect bbox of text: This was another negative fallout from 
the refactor to have text pass the baseline coordinate to the backend by 
default.

#2072: PEP8 conformance test failing: This is due to an unexpected 
interaction between setuptools and Travis

There is an additional blocker bug:

#1719: pickling gridlines: I suspect this is just an 
environmental/installation issue on the part of the OP, so I'm confident 
moving forward without that resolved.

#2024: Update homepage image: I'll get to this later tonight or tomorrow 
as part of my customary release day documentation cleaning

Cheers,
Mike

On 05/24/2013 05:40 PM, Michael Droettboom wrote:
> I've gone ahead and created the 1.3.x branch on master.  This means that
> the feature freeze on master is effectively lifted.  Any PRs for 1.3.x
> should be milestoned as such before merging (and can be merged to either
> master or the 1.3.x branch).  That milestone will indicate to me what
> needs to be on the v1.3.x branch before making the release candidate
> early next week.
>
> Mike
>
> On 05/24/2013 01:38 PM, Michael Droettboom wrote:
>> The 1.3.0 release candidate tagging is scheduled for this coming Monday,
>> May 27.  Unfortunately, due to an oversight on my part, I forgot that is
>> a holiday, so I'm going to postpone it one day to Tuesday, May 28.  I
>> will be hoping to tag the release by 23:00 UTC that day.
>>
>> I think we're in really good shape for this release, given all of the
>> great work solving and triaging bugs that's been going on since the
>> feature freeze.
>>
>> I think all of the blocker bugs (except possibly #2061) are really close
>> to being resolved.  There are a number of issues tagged for 1.3.x that
>> may unfortunately need to get punted, but not a very large number.
>>
>> Question: Should I create a 1.3.x branch now?  The upside of doing that
>> is that development of post-1.3.x things can continue on master until
>> Tuesday, of course, and I think the pool of 1.3.x things is small enough
>> for that to make sense.  The downside, of course, is that any existing
>> pull requests against master will have to be manually merged to 1.3.x.
>> That shouldn't be a big deal, though, because we don't have too many of
>> them left and I can just pull the PR logs when I'm back at the office on
>> Tuesday to find out which ones need to be merged.  Any objections to
>> creating the branch now?
>>
>> Mike
>>
>> ------------------------------------------------------------------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Closing in on 1.3.0 release candidate

[Russell E. O. <ro...@uw...>]

In article <51A...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:

> I am going to hold off one more day on making the release candidate.  
> There are three blocker bugs that were discovered over the weekend and 
> I'd like to give them a chance for review first:...

Thanks for the update.

The Mac version built fine, but I saw several warnings. The only one I'm 
worried about is use of a deprecated Numpy API:

In file included from src/_backend_agg.cpp:12:
In file included from src/_backend_agg.h:43:
In file included from src/agg_py_path_iterator.h:7:
In file included from 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/arrayobject.h:15:
In file included from 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/ndarrayobject.h:17:
In file included from 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/ndarraytypes.h:1728:
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/npy_deprecated_api.h:11:2: warning: "Using 
deprecated NumPy API, disable it by
      #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-W#warnings]
#warning "Using deprecated NumPy API, disable it by #defining 
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"


These look innocuous, but easy to fix:

./CXX/Python2/Objects.hxx:1133:23: warning: implicit conversion of NULL 
constant to 'int' [-Wnull-conversion]
            , offset( NULL )
                    ~ ^~~~

/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/npy_3kcompat.h:247:40: warning: conversion 
from string literal to 'char *' is
      deprecated [-Wdeprecated-writable-strings]
    return PyObject_CallFunction(open, "Os", filename, mode);


/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/npy_3kcompat.h:255:37: warning: conversion 
from string literal to 'char *' is
      deprecated [-Wdeprecated-writable-strings]
    ret = PyObject_CallMethod(file, "close", NULL);

Re: [matplotlib-devel] Closing in on 1.3.0 release candidate

[Michael D. <md...@st...>]

On 05/29/2013 05:23 PM, Russell E. Owen wrote:
> In article <51A...@st...>,
>   Michael Droettboom <md...@st...>
>   wrote:
>
>> I am going to hold off one more day on making the release candidate.
>> There are three blocker bugs that were discovered over the weekend and
>> I'd like to give them a chance for review first:...
> Thanks for the update.
>
> The Mac version built fine, but I saw several warnings. The only one I'm
> worried about is use of a deprecated Numpy API:
>
> In file included from src/_backend_agg.cpp:12:
> In file included from src/_backend_agg.h:43:
> In file included from src/agg_py_path_iterator.h:7:
> In file included from
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/core/include/numpy/arrayobject.h:15:
> In file included from
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/core/include/numpy/ndarrayobject.h:17:
> In file included from
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/core/include/numpy/ndarraytypes.h:1728:
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/core/include/numpy/npy_deprecated_api.h:11:2: warning: "Using
> deprecated NumPy API, disable it by
>        #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-W#warnings]
> #warning "Using deprecated NumPy API, disable it by #defining
> NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
>
>
> These look innocuous, but easy to fix:
>
> ./CXX/Python2/Objects.hxx:1133:23: warning: implicit conversion of NULL
> constant to 'int' [-Wnull-conversion]
>              , offset( NULL )
>                      ~ ^~~~
>
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/core/include/numpy/npy_3kcompat.h:247:40: warning: conversion
> from string literal to 'char *' is
>        deprecated [-Wdeprecated-writable-strings]
>      return PyObject_CallFunction(open, "Os", filename, mode);
>
>
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/core/include/numpy/npy_3kcompat.h:255:37: warning: conversion
> from string literal to 'char *' is
>        deprecated [-Wdeprecated-writable-strings]
>      ret = PyObject_CallMethod(file, "close", NULL);
>
These are tricky, as we want to continue to support earlier versions of 
Numpy.  (Officially, we support back to 1.4, though only 1.6 and later 
is getting regular testing).  Last time I looked, there wasn't a good 
way to do this without a lot of #ifdefs that would just make the 
maintenance more complicated.

However, perhaps for the next major release we should consider dropping 
Numpy < 1.5 and fixing up these deprecation warnings.

Mike