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...@stsci.edu> 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
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
------------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
