[Matplotlib-devel] supported python versions

[Thomas Caswell]

I really meant v2.0.1 (as in the first micro / bug fix release for 2.0.

I am hoping to not do 1.5.x bug fix releases unless someone asks for them.
We historically have not done bug fixes on the previous released version
(ex, we did not do a 1.3.2 and will not do a 1.4.4).

Tom

On Sat, Sep 26, 2015 at 10:24 PM Benjamin Root <ben.v.root at gmail.com> wrote:

> Just realized something. Do you mean v2.0.1 or v2.1.0?
>
> Also, what is the plan for v1.5.x? If we release a bugfix release of v2.0,
> does that mean a bugfix release of v1.5 as well?
>
> Ben Root
> On Sep 26, 2015 5:29 PM, "Thomas Caswell" <tcaswell at gmail.com> wrote:
>
>> Having not heard anything back, I am going to take that as agreement :)
>>
>> The plan will be:
>>
>>    v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6,
>> and 3.3
>>    v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6,
>> and 3.3
>>    v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3
>>
>> The mechanics of this will be after 2.0:
>>    - we reduce the travis test matrix to just 2.7, 3.4, 3.5,
>>    - any syntax related bug reports (mostly set literal and ordereddict)
>> are closed as not supported
>>    - review and merge 2.6/3.3 specific patches
>>
>> Tom
>>
>> On Tue, Sep 15, 2015 at 9:20 AM Thomas Caswell <tcaswell at gmail.com>
>> wrote:
>>
>>> Nathaniel and Daniele: I think OceanWolf hit it on the head, I see this
>>> as orthogonal to the 'style only' marketing of 2.0.  The idea is that 2.0
>>> will still work with 2.6, but we are not committing to the bug-fix releases
>>> working with 2.6.  The alternative to dropping py2.6 for 2.0 is dropping it
>>> for 1.5 and in that, we might as well drop 3.3 for 1.5 as well.  My only
>>> hesitation is the lead time and that 1.5 will work with 2.6 and 3.3.  How
>>> about this instead:
>>>
>>>   v1.5.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6,
>>> and 3.3
>>>   v2.0.0 is supported in 2.7, 3.4, 3.5 and is known to work with 2.6,
>>> and 3.3
>>>   v2.0.1 is supported in 2.7, 3.4, 3.5 and is known to work with 3.3
>>>
>>> and when we break something in the 'known to work with' section we just
>>> remove it from the listing in the next release (even a micro).
>>>
>>> Daniele: The plan for python3 only code is to make a new module(s).  I
>>> think we can be careful about which way dependencies go and only have to
>>> have conditional imports in `pyplot`, if at all. The features I am most
>>> excited about are keyword-only args (which will help make our APIs which
>>> have a tremendous number of pass through kwargs easier to work
>>> with/document) and the signature rewriting (which allows for higher-order
>>> functions to propagate signatures).  No functionality is lost in python2
>>> and if you are using python3 you get the new features (by importing the new
>>> modules).  If users are committed to python2 support then obviously they do
>>> not get to use the new features (ex other libraries), but in my from my
>>> personal experience a vast majority of the code I write that uses mpl (that
>>> is not in mpl core) is small standalone scripts or at the repl.  As more
>>> people switch to python3 as their daily driver the number of 'python 3 only
>>> projects', very broadly scoped, is going to sky rocket so I think in a year
>>> this will be not be a big deal.
>>>
>>> Ryan: enum and single-dispatch are the most compelling 3.4+ only feature
>>> for us, but there are back-ported versions of both.  It also makes all of
>>> our supported python3 versions in the random dict-iteration camp.  I am
>>> tempted to suggest we only support 3.5 to get the infix mul operator and
>>> then generalized unpacking syntax! (2.7, 3.5 woul
>>>
>>> To be clear, what I mean by 'supported versions of python' is that if a
>>> user reports a bug specific to an older version of python the mpl
>>> developers should not feel guilty about not fixing it, but we will consider
>>> reasonable patches which fix it.
>>>
>>> Again, if 2.6 support is critical for anyone, please reach out, we would
>>> love to work with you.
>>>
>>> Tom
>>>
>>> On Tue, Sep 15, 2015 at 7:18 AM Daniele Nicolodi <daniele at grinta.net>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> On 14/09/15 21:49, Thomas Caswell wrote:
>>>> > I would like to propose the following for which version of python mpl
>>>> > officially supports:
>>>> >
>>>> >  - for v1.5 we continue to support 2.6, 2.7, 3.3-3.5
>>>> >  - for v2.0 forward we support (2.7, 3.4, 3.5)
>>>> >
>>>> > and allow for new, python3 only, features to be developed for mpl2.1
>>>> > onward, so long as they do not break any existing functionality in
>>>> py2.7.
>>>>
>>>> I agree that dropping support for python 2.6 may be a good idea if there
>>>> are real advantages in doing so, but maybe not in release 2.0 that was
>>>> advertised to be only about style changes.
>>>>
>>>> However, I do not see how it may be possible to have python3 only
>>>> features added in the code-base, without cluttering it with a lot of
>>>> conditionals imports and versions checks. What are exactly the python3
>>>> features you thing may easy the implementation of matplotlib features?
>>>> How do you plan to make python3 only code coexist with the existing
>>>> pythin2/3 code?
>>>>
>>>> Cheers,
>>>> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150927/186b8a4f/attachment.html>