Release planning/milestones

Hey all,

To start with, the 2.0 release is pending a choice of new default color map. I think that when we pick that we should cut 2.0 off of the last release and then the next minor release turns into 2.1. If we want to do other breaking changes we will just do a 3.0 when that happens. It makes sense to me to bundle default color changes as one set of breaking changes and code API changes as another.

Eric made the case in an issue that we should not continue the 1.4.x series and start working 1.5.0, which fits well with aiming for a 6month scheduled release cycle (minor release in July, bug-fix release in February).

To this end, I have clean out and close the 1.4.x milestone (most of issues just got moved 1.5.0) and created a 1.5.0 milestone. I set a target for 1.5.0 to be released at scipy as that seems like a reasonable thing to. Targeting just after SciPy also makes sense so we have a clear list of things to work on at the sprints. Thoughts?

My internal list of what we should try to get in for 1.5.0 are:

  • visitor pattern on all artists + recreating figure from it’s visited artists. This gets us a) proper serialization of our figures instead of going through pickles and b) makes interoperability with plotly/b3/bokeh easier

  • pyplot overhaul (use decorators, provide decorators as part of public API)

  • navigation by events (PR #3652 + MEP22)

  • making OO interface easier to use interactively (if interactive, auto-redraw at sensible time)

  • pull the pyplot state machine out of backend_bases and expose the figure_manager classes

  • overhaul the website

Anything else people think should be on the list or any protests to this list?

Tom

Hi all!

···

On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell <tcaswell@...149...> wrote:

Hey all,

To start with, the 2.0 release is pending a choice of new default color map.
I think that when we pick that we should cut 2.0 off of the last release and
then the next minor release turns into 2.1. If we want to do other breaking
changes we will just do a 3.0 when that happens. It makes sense to me to
bundle default color changes as one set of breaking changes and code API
changes as another.

Eric made the case in an issue that we should not continue the 1.4.x series
and start working 1.5.0, which fits well with aiming for a 6month scheduled
release cycle (minor release in July, bug-fix release in February).

Do I understand correctly you plan to maintain 2 separate development
lines (like Python with 2.x and 3.x) as 1.5.x and 2.x ?

Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hey all,

To start with, the 2.0 release is pending a choice of new default color map. I think that when we pick that we should cut 2.0 off of the last release and then the next minor release turns into 2.1. If we want to do other breaking changes we will just do a 3.0 when that happens. It makes sense to me to bundle default color changes as one set of breaking changes and code API changes as another.

I thought there was going to be a complete overhaul of the default theme? Has that idea been abandoned?

  • making OO interface easier to use interactively (if interactive, auto-redraw at sensible time)

  • pull the pyplot state machine out of backend_bases and expose the figure_manager classes

Do either of these mean that it will be possible to use the OO interface without needing to go through pyplot?

···

On Feb 8, 2015 1:13 AM, “Thomas Caswell” <tcaswell@…149…> wrote: