From: Thomas C. <tca...@gm...> - 2015-02-08 00:13:13
|
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 |
From: Sandro T. <mo...@de...> - 2015-02-08 19:04:31
|
Hi all! On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell <tca...@gm...> 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 |
From: Thomas C. <tca...@gm...> - 2015-02-08 19:11:11
|
Ah, no I mean the exact opposite! My proposal is to cut 2.0 off of what ever the current stable release is (ex, 1.4.3) and then merge that into master. The next minor release would then be 2.1 and there would be no new 1.Y releases. Tom On Sun Feb 08 2015 at 2:04:24 PM Sandro Tosi <mo...@de...> wrote: > Hi all! > > On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell <tca...@gm...> > 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 > |
From: Todd <tod...@gm...> - 2015-02-08 21:50:20
|
On Feb 8, 2015 1:13 AM, "Thomas Caswell" <tca...@gm...> 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. 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? |
From: Thomas C. <tca...@gm...> - 2015-02-08 22:05:46
|
To overhauling all of the default colors, I think that is still in the cards, but some one who is not me needs to drive that. The goal of pulling pyplot out of backend_bases is exactly that, to be able to do everything using the OO interface in a convenient way. Tom On Sun Feb 08 2015 at 4:50:51 PM Todd <tod...@gm...> wrote: > > On Feb 8, 2015 1:13 AM, "Thomas Caswell" <tca...@gm...> 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. > > 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? > ------------------------------------------------------------ > ------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Eric F. <ef...@ha...> - 2015-02-08 22:19:10
|
On 2015/02/08 12:05 PM, Thomas Caswell wrote: > The goal of pulling pyplot out of backend_bases is exactly that, to be > able to do everything using the OO interface in a convenient way. > https://github.com/matplotlib/matplotlib/pull/4082 The above PR is an illustration of one approach to making the OO interface draw like the pyplot interface does in interactive mode. There may be a better way to do it, but this way is quite simple and non-intrusive. Eric |
From: Todd <tod...@gm...> - 2015-02-17 08:56:56
|
I wasn't referring to just the default colors, but the default style in general. Things like background, line thickness, padding, ticks, etc. I thought that there was agreement that the default matplotlib style is not optimal, and that the point of the 2.0 release was to put all the stylistic changes in one release so people don't have to keep changing their unit tests. On Feb 8, 2015 11:04 PM, "Thomas Caswell" <tca...@gm...> wrote: > > To overhauling all of the default colors, I think that is still in the cards, but some one who is not me needs to drive that. > > The goal of pulling pyplot out of backend_bases is exactly that, to be able to do everything using the OO interface in a convenient way. > > Tom > > On Sun Feb 08 2015 at 4:50:51 PM Todd <tod...@gm...> wrote: >> >> >> On Feb 8, 2015 1:13 AM, "Thomas Caswell" <tca...@gm...> 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. >> >> 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? >> >> ------------------------------------------------------------------------------ >> >> Dive into the World of Parallel Programming. The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net/_______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |