[Matplotlib-devel] supported python versions

Thu Oct 8 15:52:47 EDT 2015

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.

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.

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.  Dropping support for old version of python will be
noted there and in the release notes, but not mentioned anywhere else.

So where I currently sit:

 - 1.5 onward; supports 2.7, 3.4, 3.5
 - individual releases will be coded for what versions of python they _run_
on

And again, if 2.6 support is critical to anyone, let us know and we will
see what we can do.

Tom

[1] https://github.com/matplotlib/matplotlib/pull/5215

On Mon, Sep 28, 2015 at 9:29 AM Benjamin Root <ben.v.root at gmail.com> wrote:

> 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.
>
> Ben Root
>
> On Mon, Sep 28, 2015 at 7:58 AM, Thomas Robitaille <
> thomas.robitaille at gmail.com> wrote:
>
>> If Python 2.6 and 3.3 support is completely dropped in Matplotlib 1.5
>> and 2.0, I don't think you will hear (m)any complaints from users. When
>> I did a survey earlier this year, only 2% of users were on Python 2.6
>> and 1% on 3.3:
>>
>> http://astrofrog.github.io/blog/2015/05/09/2015-survey-results/
>>
>> From an external point of view (since I am not a Matplotlib core dev),
>> I personally think option C makes more sense, i.e. still officially
>> supporting 2.6 and 3.3 in 1.5 (all the hard work is done) and then
>> dropping support in 2.0.
>>
>> Cheers,
>> Tom
>>
>> Daniele Nicolodi wrote:
>> > On 27/09/15 21:49, Thomas Caswell wrote:
>> >> We already have this 'know to work with' vs 'supported' distinction,
>> >> this is the current state of python 3.2 support.  We don't test on it,
>> >> my response to 3.2 specific bugs is 'upgrade', but if we get
>> reasonable,
>> >> non-destructive patches they will get merged (which we have done,
>> around
>> >> the 1.4 release, after we dropped 3.2, we merged some patches
>> >> from Christoph Gohlke which fixed 3.2 on windows).
>> >>
>> >> The reality is that we should have had this discussion 6-12 months ago
>> >> (sorry OceanWolf), instead of on the cusp of a release, and currently
>> >> master (and hence both the 1.5.0 and 2.0 releases) _will_ work with
>> >> py2.6 and py3.3 because we are currently testing on them.  There is
>> >> consensus in the core developers that we will not support py2.6/3.3
>> >> going forward so the question is what to do about the upcoming
>> >> releases.
>> > I agree that this discussion would have been better when the 1.5 and 2.0
>> > releases were planned, but I don't see much of a problem in defining
>> > things now, as not disruptive changes have been made to the codebase.
>> >
>> > I agree that dropping support for python 2.6 and 3.3 is the way to go.
>> > What I'm objecting is the "labeling" you are suggesting both in the
>> > sense of the "supported" vs "known to work with" terminology and with
>> > release numbers.
>> >
>> > As Nathaniel pointed out it does not make much sense to drop support for
>> > python 2.6 and 3.3 in a micro/patch level release. I think it makes much
>> > more sense to plan to have a 2.1 release after 2.0 in which new features
>> > could be added and old python versions support removed. Then 2.0 becomes
>> > a bugfix only branch. I haven't looked at the code, but I believe that
>> > the only difference between 1.5 and 2.0 are the style defaults, so, if
>> > there is demand, I don't see a problem to also backport bugfixes to the
>> > 1.5 branch and release 1.5 series bugfixes.
>> >
>> >>  The options are:
>> >>
>> >>  - do not document at all that as far as we know 1.5/2.0 will work on
>> on
>> >> py2.6
>> >>  - document that as far as we know mpl does work on py2.6, but are
>> >> making no commitment to make sure that stays true.
>> > There is another option:
>> >
>> >  - keep supporting python 2.6 and 3.3 on 1.5 and 2.0 and drop support on
>> > 2.1 where new development that can benefit from new python features
>> > should happen
>> >
>> >> Danielle: If you are volunteering to maintain 1.5.x/2.0.x branches
>> which
>> >> back ports bug fixes in a 2.6 compatibly that would be great, otherwise
>> >> given the limited resources the project currently has, that is not
>> >> something we can.
>> > I can try to contribute a bit, but, as I was trying to explain above,
>> > I'm not opposing to drop support for old python releases, but merely to
>> > the labeling and wording.
>> >
>> >> I have already linked to this article is this thread, but once more for
>> >> good measure:
>> >>
>> http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html
>> > As the work to make 1.5 and 2.0 releases work with python 2.6 and 3.3
>> > has already been done, I don't think this article is much relevant to
>> > the discussion. I'm all in favor of not keeping python 2.6 support, and
>> > I don't think that anyone that uses python 3 is stuck with an old python
>> > 3.3. But given that we already have the support for those release,
>> > please keep it and drop it in a future release.
>> >
>> > Cheer,
>> > Daniele
>> >
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Matplotlib-devel at python.org
>> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20151008/80eefc16/attachment.html>