[Matplotlib-devel] supported python versions
Nathan Goldbaum
nathan12343 at gmail.com
Thu Oct 8 16:16:25 EDT 2015
Sorry to jump into this discussion, but why not just drop support for
2.6 completely in 1.5? Sure, it may work, but you're not committed to
backporting bugfixes so it likely won't continue to work.
Also, dropping support may bring some CentOS users out of the woodwork to
beg for 2.6 support post-release...
On Thursday, October 8, 2015, Thomas Caswell <tcaswell at gmail.com> wrote:
> Sigh, all of my attempts to do this gracefully are failing :(
>
> On Thu, Oct 8, 2015 at 3:57 PM Nathaniel Smith <njs at pobox.com
> <javascript:_e(%7B%7D,'cvml','njs at pobox.com');>> wrote:
>
>> 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.
>> On Oct 8, 2015 12:53, "Thomas Caswell" <tcaswell at gmail.com
>> <javascript:_e(%7B%7D,'cvml','tcaswell at gmail.com');>> wrote:
>>
>>> 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
>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>> <javascript:_e(%7B%7D,'cvml','Matplotlib-devel at python.org');>
>>>>> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Matplotlib-devel at python.org
>>>>> <javascript:_e(%7B%7D,'cvml','Matplotlib-devel at python.org');>
>>>>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>>>>
>>>>
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Matplotlib-devel at python.org
>>>> <javascript:_e(%7B%7D,'cvml','Matplotlib-devel at python.org');>
>>>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>>>
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel at python.org
>>> <javascript:_e(%7B%7D,'cvml','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/0663cd31/attachment-0001.html>
More information about the Matplotlib-devel
mailing list