<p dir="ltr">I should have said "no more api breakage than normal between point releases".</p>
<p dir="ltr">We do not want to get in to a situation where major down stream packages that is mpl (yt, skimage, pandas, etc) pin a maximum matplotlib version.</p>
<p dir="ltr">Tom</p>
<br><div class="gmail_quote"><div dir="ltr">On Fri, May 20, 2016, 14:32 Eric Firing <<a href="mailto:efiring@hawaii.edu">efiring@hawaii.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2016/05/20 8:18 AM, OceanWolf via Matplotlib-devel wrote:<br>
> How does "not breaking any APIs" influence the deprecation and removal<br>
> timeline for the gui overhaul?  I thought perhaps deprecate in 2.2 and<br>
> remove in 3.0?  Or does such a timeline go too fast?<br>
><br>
Along the same lines, I think this might be too much of a straitjacket.<br>
This is a vague sense of unease--I don't have a specific example.  It<br>
just seems like having to keep *everything* 100% intact until a 4.0<br>
release in 2019 or 2020 might be going too far.  This is especially so<br>
since "API" is not so well defined.  Does every attribute lacking a<br>
leading underscore have to be maintained for several more years?  Maybe<br>
"API" needs a qualifier, like "major API".<br>
<br>
Eric<br>
<br>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</blockquote></div>