<p dir="ltr">Clarity is nine-tenths of grace :-)</p>
<div class="gmail_quote">On Oct 8, 2015 1:13 PM, "Thomas Caswell" <<a href="mailto:tcaswell@gmail.com">tcaswell@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sigh, all of my attempts to do this gracefully are failing :(</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 8, 2015 at 3:57 PM Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">FWIW (which may not be much, none of this probably matters terribly :-)), if I saw py26 wheels on pypi or "Python :: 2 :: 2.6" in the trove classifiers, then I'd assume without thinking about it that this meant that 2.6 was supported.</p>
<div class="gmail_quote">On Oct 8, 2015 12:53, "Thomas Caswell" <<a href="mailto:tcaswell@gmail.com" target="_blank">tcaswell@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I did not include D because, baring someone making a hard commitment to maintain a 2.6 compatible 2.0.x bug-fix branches, it is not an option.<div><br></div><div>One of the major planned features for 2.1 is serialization which is being built on top of traitlets, which does not support py2.6.  I have an open PR to drop [1] travis testing for 2.6/3.3 and master will lose 2.6 support (probably) within the month.</div><div><br></div><div>After a bit more thinking, I think the right way to communicate the distinction between 'works' and 'supported' is to only list the supported versions (as in, we are committing to fixing it if mpl breaks on this version of python) the website, but code the pypi packages for all versions where it will run.  <span style="line-height:1.5">Dropping support for old version of python will be noted there and in the release notes, but not mentioned anywhere else.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">So where I currently sit:</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5"> - 1.5 onward; supports 2.7, 3.4, 3.5</span></div><div> - individual releases will be coded for what versions of python they _run_ on</div><div><span style="line-height:1.5"> </span><br></div><div><span style="line-height:1.5">And again, if 2.6 support is critical to anyone, let us know and we will see what we can do.</span></div><div><br></div><div>Tom</div><div><br></div><div>[1] <a href="https://github.com/matplotlib/matplotlib/pull/5215" target="_blank">https://github.com/matplotlib/matplotlib/pull/5215</a></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 28, 2015 at 9:29 AM Benjamin Root <<a href="mailto:ben.v.root@gmail.com" target="_blank">ben.v.root@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I am for either C or D. It makes zero sense to me to drop 2.6/3.3 on a bugfix release, which is why I thought that v2.0.1 was a typo earlier.<br><br></div>Ben Root<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 28, 2015 at 7:58 AM, Thomas Robitaille <span dir="ltr"><<a href="mailto:thomas.robitaille@gmail.com" target="_blank">thomas.robitaille@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If Python 2.6 and 3.3 support is completely dropped in Matplotlib 1.5<br>
and 2.0, I don't think you will hear (m)any complaints from users. When<br>
I did a survey earlier this year, only 2% of users were on Python 2.6<br>
and 1% on 3.3:<br>
<br>
<a href="http://astrofrog.github.io/blog/2015/05/09/2015-survey-results/" rel="noreferrer" target="_blank">http://astrofrog.github.io/blog/2015/05/09/2015-survey-results/</a><br>
<br>
>From an external point of view (since I am not a Matplotlib core dev),<br>
I personally think option C makes more sense, i.e. still officially<br>
supporting 2.6 and 3.3 in 1.5 (all the hard work is done) and then<br>
dropping support in 2.0.<br>
<br>
Cheers,<br>
Tom<br>
<div><div><br>
Daniele Nicolodi wrote:<br>
> On 27/09/15 21:49, Thomas Caswell wrote:<br>
>> We already have this 'know to work with' vs 'supported' distinction,<br>
>> this is the current state of python 3.2 support.  We don't test on it,<br>
>> my response to 3.2 specific bugs is 'upgrade', but if we get reasonable,<br>
>> non-destructive patches they will get merged (which we have done, around<br>
>> the 1.4 release, after we dropped 3.2, we merged some patches<br>
>> from Christoph Gohlke which fixed 3.2 on windows).<br>
>><br>
>> The reality is that we should have had this discussion 6-12 months ago<br>
>> (sorry OceanWolf), instead of on the cusp of a release, and currently<br>
>> master (and hence both the 1.5.0 and 2.0 releases) _will_ work with<br>
>> py2.6 and py3.3 because we are currently testing on them.  There is<br>
>> consensus in the core developers that we will not support py2.6/3.3<br>
>> going forward so the question is what to do about the upcoming<br>
>> releases.<br>
> I agree that this discussion would have been better when the 1.5 and 2.0<br>
> releases were planned, but I don't see much of a problem in defining<br>
> things now, as not disruptive changes have been made to the codebase.<br>
><br>
> I agree that dropping support for python 2.6 and 3.3 is the way to go.<br>
> What I'm objecting is the "labeling" you are suggesting both in the<br>
> sense of the "supported" vs "known to work with" terminology and with<br>
> release numbers.<br>
><br>
> As Nathaniel pointed out it does not make much sense to drop support for<br>
> python 2.6 and 3.3 in a micro/patch level release. I think it makes much<br>
> more sense to plan to have a 2.1 release after 2.0 in which new features<br>
> could be added and old python versions support removed. Then 2.0 becomes<br>
> a bugfix only branch. I haven't looked at the code, but I believe that<br>
> the only difference between 1.5 and 2.0 are the style defaults, so, if<br>
> there is demand, I don't see a problem to also backport bugfixes to the<br>
> 1.5 branch and release 1.5 series bugfixes.<br>
><br>
>>  The options are:<br>
>><br>
>>  - do not document at all that as far as we know 1.5/2.0 will work on on<br>
>> py2.6<br>
>>  - document that as far as we know mpl does work on py2.6, but are<br>
>> making no commitment to make sure that stays true.<br>
> There is another option:<br>
><br>
>  - keep supporting python 2.6 and 3.3 on 1.5 and 2.0 and drop support on<br>
> 2.1 where new development that can benefit from new python features<br>
> should happen<br>
><br>
>> Danielle: If you are volunteering to maintain 1.5.x/2.0.x branches which<br>
>> back ports bug fixes in a 2.6 compatibly that would be great, otherwise<br>
>> given the limited resources the project currently has, that is not<br>
>> something we can.<br>
> I can try to contribute a bit, but, as I was trying to explain above,<br>
> I'm not opposing to drop support for old python releases, but merely to<br>
> the labeling and wording.<br>
><br>
>> I have already linked to this article is this thread, but once more for<br>
>> good measure:<br>
>> <a href="http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html" rel="noreferrer" target="_blank">http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html</a><br>
> As the work to make 1.5 and 2.0 releases work with python 2.6 and 3.3<br>
> has already been done, I don't think this article is much relevant to<br>
> the discussion. I'm all in favor of not keeping python 2.6 support, and<br>
> I don't think that anyone that uses python 3 is stuck with an old python<br>
> 3.3. But given that we already have the support for those release,<br>
> please keep it and drop it in a future release.<br>
><br>
> Cheer,<br>
> Daniele<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>
_______________________________________________<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>
</div></div></blockquote></div><br></div>
_______________________________________________<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>
<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>
<br></blockquote></div>
</blockquote></div>
</blockquote></div>