matplotlib-devel Mailing List for matplotlib

Great news! A lot of fantastic work has been done by a whole host of people
to go into this release. It's exciting stuff!

May 27th sounds like a sensible target to me. As you know, I'm an advocate
of releasing often - the more frequently we make a release, the less we
will have the "impending release rush" that can really hamper the whole
release process.

Cheers,




On 11 April 2013 17:38, Michael Droettboom <md...@st...> wrote:

> Congrats to everyone on a successful 1.2.1 -- there was a relatively
> small influx of bug reports following it -- perhaps a sign of improving
> quality?
>
> In any event, as Phil Elson likes to repeatedly point out (<wink>), we
> have a great deal of awesome new features in master that it would be
> great to get out.  As for time frame, I think if we aim for a 1.3.0rc1
> of May 27, that's within a good time frame to get something out in time
> for Scipy.  That will put us about 8 months past 1.2.0, which is not far
> off from my eventual goal of 6 month releases once things get
> streamlined.  We can, of course, adjust the date as necessary as we go
> along.
>
> So... let the bug triaging begin!  As there are lot of new features in
> the queue, I think it's important to distinguish the "nice to have" from
> the "must have".  I've created a new milestone "1.3.x blocker" that we
> should use for critical bugs that should hold up the release.  All other
> new features that are looking close to ready for 1.3.x should be
> milestoned 1.3.x, and as we get closer, we can punt those on to 1.4.x.
> Simple bugs that apply to 1.2.x as well as master should be milestoned
> as "1.2.x" and merged onto the "v1.2.x" branch (as we've been doing), as
> I still think we should reserve the right to make another 1.2.2 bugfix
> release if necessary.
>
> There are a couple major ongoing projects that I think we'll need to get
> to a steady interim state before we can make another release.
>
>    MEP10: Documentation
>
>       We already have a number of improved docstrings, and better
> organization throughout.  I don't think we need to finish all of this
> work before the next release, but we should get it back into shape so
> that the doc build has fewer warnings (#1896) and the LaTeX build works
> again (#1836).
>
>    MEP12: Reorganize and cleanup examples
>
>       Again, I think a lot of great work has already been done, and we
> don't necessarily have to wait until it's done.
>
> For both of the above, it would be nice to divide the work up so the
> leaders of those projects are less individually burdened.  Nelle and
> Tony, if you know of any critical blockers or loose ends that should be
> tied up before a release should be made, please make issues for them and
> milestone them as "1.3.x blocker".
>
> Cheers,
> Mike
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Congrats to everyone on a successful 1.2.1 -- there was a relatively 
small influx of bug reports following it -- perhaps a sign of improving 
quality?

In any event, as Phil Elson likes to repeatedly point out (<wink>), we 
have a great deal of awesome new features in master that it would be 
great to get out.  As for time frame, I think if we aim for a 1.3.0rc1 
of May 27, that's within a good time frame to get something out in time 
for Scipy.  That will put us about 8 months past 1.2.0, which is not far 
off from my eventual goal of 6 month releases once things get 
streamlined.  We can, of course, adjust the date as necessary as we go 
along.

So... let the bug triaging begin!  As there are lot of new features in 
the queue, I think it's important to distinguish the "nice to have" from 
the "must have".  I've created a new milestone "1.3.x blocker" that we 
should use for critical bugs that should hold up the release.  All other 
new features that are looking close to ready for 1.3.x should be 
milestoned 1.3.x, and as we get closer, we can punt those on to 1.4.x.  
Simple bugs that apply to 1.2.x as well as master should be milestoned 
as "1.2.x" and merged onto the "v1.2.x" branch (as we've been doing), as 
I still think we should reserve the right to make another 1.2.2 bugfix 
release if necessary.

There are a couple major ongoing projects that I think we'll need to get 
to a steady interim state before we can make another release.

   MEP10: Documentation

      We already have a number of improved docstrings, and better 
organization throughout.  I don't think we need to finish all of this 
work before the next release, but we should get it back into shape so 
that the doc build has fewer warnings (#1896) and the LaTeX build works 
again (#1836).

   MEP12: Reorganize and cleanup examples

      Again, I think a lot of great work has already been done, and we 
don't necessarily have to wait until it's done.

For both of the above, it would be nice to divide the work up so the 
leaders of those projects are less individually burdened.  Nelle and 
Tony, if you know of any critical blockers or loose ends that should be 
tied up before a release should be made, please make issues for them and 
milestone them as "1.3.x blocker".

Cheers,
Mike