We now have the style system in-place. I envision the 1.5 release as having
the attempt at encoding the current visual style as "classic" (which would
be default), and to put together a "bleeding" (or "trendy" or "hipster")
style that would encode many of the proposed changes to the defaults. Come
mpl2.0, any remaining bugs in the style system should be ironed out, and we
can canonicalize the "hipster" style into a "stable" style. We can even
then utilize "hipster" as a playground of sorts to get feedback on proposed
changes that would work their way into "stable". Each release could also
alias "stable" with a "mplX.Y" style. Another reason why I like this
approach is that it gives us a way to explicitly deprecate various styles
(with warnings and user notes) if an older style becomes a maintenance
burden as matplotlib evolves.
I am also liking the argument that mpl2.0 should be focused on just visual
changes. And logically organized styles will provide users with the needed
"out" to hang onto most of the old visual styles (they would just need to
add a single line to their programs or maybe a config file somewhere).
I am still not convinced that all of the CXX/AGG issues have been ironed
out. While nominal situations seems to have been fairly straight-forward, I
am concerned about error-handling in the interactive backends. As I have
already discovered, the change did introduce a segfaulting error handling
path that merely errored out previously (seems to be fixed now with the
copy constructor fix). These sorts of things aren't covered by our test
suite and can be very backend-dependent.
Cheers!
Ben Root
On Sat, Nov 22, 2014 at 5:16 AM, Phil Elson <pelson....@gmail.com> wrote:
> Given the workload that making a release causes, is it necessary to put
> out a v1.4.3 at all? On a similar sounding argument, given that the removal
> of CXX doesn't break user APIs, and has been on master for several weeks
> with fewer than anticipated side-effects, do we even need a v1.5?
> Essentially, what is the barrier from moving straight to a v2.0 in Feb?
>
> What I'd like to avoid is this idea of "we're talking about a making a
> major release so let's fix everything that was ever broken" - my definition
> of a v2.0 release is really just v1.5+new default cmap. If there are other
> things that need fixing in a backwards incompatible way then we should
> discuss and plan how we are going to do that, and if there is developer
> appetite, there is no reason not to talk about releasing a v3.0 in 18-24
> months (which is currently ~2 mpl minor release cycles).
>
>
> On 21 November 2014 18:56, Thomas Caswell <tcasw...@gmail.com> wrote:
>
>> I am a bit wary of doing a 2.0 _just_ to change the color map, but when
>> every I try to write out why, they don't sound convincing. We may end up
>> with a 3.0 within a year or so due to the possible plotting API/pyplot work
>> that is (hopefully) coming.
>>
>> If we are going to do this, I think we should do the 1.4.3 release
>> (scheduled for Feb 1, RCs in mid January), then put one commit to change
>> the color map on top of that, tag 2.0 and then master turns into 2.1.x
>> (targeted for right after scipy?).
>>
>> There is also the thought to get the major c++ refactor work tagged and
>> released sooner rather than later so maybe we want to do 1.4.3, 1.5.0 and
>> 2.0 in Feb with 2.0 based off of 1.5 not 1.4.
>>
>> On Fri Nov 21 2014 at 12:52:03 PM Benjamin Root <ben.r...@ou.edu> wrote:
>>
>>> As a point of clarification, is this proposed 2.0 release different from
>>> the 1.5 release?
>>>
>>> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pelson....@gmail.com>
>>> wrote:
>>>
>>>> Many of you will be aware of there has been an ongoing issue (#875,
>>>> http://goo.gl/xLZvuL) which recommends the removal of Jet as the
>>>> default colormap in matplotlib.
>>>>
>>>> The argument against Jet is compelling and I think that as a group who
>>>> care about high quality visualisation we should be seriously discussing how
>>>> matplotlib can move beyond Jet.
>>>>
>>>> There was recently an open letter to the climate science community
>>>> <http://www.climate-lab-book.ac.uk/2014/end-of-the-rainbow/> asking
>>>> for scientists to "pledge" against using rainbow like colormaps (such as
>>>> Jet), and there are similar initiatives in other scientific fields, as well
>>>> as there being a plethora of well researched literature on the subject.
>>>>
>>>> As such, it's time to agree on a solution on how matplotlib can reach
>>>> the end of the rainbow.
>>>>
>>>>
>>>> The two major hurdles, AFAICS, to replacing the three little characters
>>>> which control the default colormap of matplotlib are:
>>>>
>>>> * We haven't had a clear (decisive) discussion about what we should
>>>> replace Jet with.
>>>> * There are concerns about changing the default as it would change the
>>>> existing widespread behaviour.
>>>>
>>>> To address the first point I'll start a new mailinglist thread
>>>> (entitled "Matplotlib's new default colormap") where new default colormap
>>>> suggestions can be made. The thread should strictly avoid "+1" type
>>>> comments, and generally try to stick to reference-able/demonstrable fact,
>>>> rather than opinion. There *will* be a difference of opinion, however
>>>> the final decision has to come down to the project lead (sorry Mike) who I
>>>> know will do whatever is necessary to make the best choice for matplotlib.
>>>>
>>>> The second point is a reasonable response when we consider that
>>>> matplotlib as a project has no *clear* statement on backwards
>>>> compatibility. As a result, matplotlib is highly change averse between
>>>> minor releases (to use semantic versioning terms) and therefore changing
>>>> the default colormap is unpalatable in the v1.x release series. As a result
>>>> I'd like to propose that the next release of matplotlib be called 2.0, with
>>>> the *only* major backwards-incompatible change be the removal of Jet
>>>> as the default colormap.
>>>>
>>>> As a project matplotlib mustn't get caught up in the trap of shying
>>>> away from a major version release when the need arises, and in my opinion
>>>> helping our users to avoid using a misleading colormap is a worthy cause
>>>> for a v2.0.
>>>>
>>>> Please try to keep this thread on the "how", and not on the "what" of
>>>> the replacement default colormap, for which there is a dedicated thread.
>>>>
>>>> Thanks,
>>>>
>>>> Phil
>>>>
>>>> (#endrainbow)
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>> more
>>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Matplotlib-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&;
>>> iu=/4140/ostg.clktrk_______________________________________________
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
