supported python versions

Development matplotlib-devel
1

Hey all,

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.

We already support all of those versions on master, there is no good reason
to drop 2.6 support right before the RC. For 2.0 we should drop 2.6 so
that we do not have to maintain a mpl2.0.x py2.6 compatible bug-fix branch.

Regarding dropping 2.6 as a supported version I suggest you read/watch the
following from Nick Coghlan:

http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html
http://www.pyvideo.org/video/3764/contributors-colleagues-clients-customers-su

We are resource limited and those resources would be better spent improving
the library and supporting modern version of python. At some point it is
unreasonable for people running very old installations of python to expect
the the newest versions of down-stream tools to work. If this is important
to someone, please step up to mange maintaining a 1.5.x bug-fix branch
which will maintain 2.6 compatibility.

Dropping 2.6 will also free us to being using OrderedDict and several other
language features added in 2.7.

Regarding dropping 3.3, every survey has shown that among the users who
have adopted py3, a vast majority are using the newest version so
supporting and testing against the older versions of 3 is not worth the
effort.

In all cases, versions of mpl that currently work on legacy versions of
python will continue to work.

Thanks to Eric, Mike, and Phil who have this a read over.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150914/7585bdb0/attachment.html>

2

It seems like a good idea in general to me, but doesn't it kinda undermine
the "2.0 is style changes only" idea/messaging? I assume the maintenance
burden of supporting the old versions in 2.0 won't be large compared to 1.5
given this... Maybe 2.1 (or 1.5!) would be a better place to draw the line?

···

On Sep 14, 2015 12:49 PM, "Thomas Caswell" <tcaswell at gmail.com> wrote:

Hey all,

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.

We already support all of those versions on master, there is no good
reason to drop 2.6 support right before the RC. For 2.0 we should drop 2.6
so that we do not have to maintain a mpl2.0.x py2.6 compatible bug-fix
branch.

Regarding dropping 2.6 as a supported version I suggest you read/watch the
following from Nick Coghlan:

Stop Supporting Python 2.6 (For Free) | Curious Efficiency

http://www.pyvideo.org/video/3764/contributors-colleagues-clients-customers-su

We are resource limited and those resources would be better spent
improving the library and supporting modern version of python. At some
point it is unreasonable for people running very old installations of
python to expect the the newest versions of down-stream tools to work. If
this is important to someone, please step up to mange maintaining a 1.5.x
bug-fix branch which will maintain 2.6 compatibility.

Dropping 2.6 will also free us to being using OrderedDict and several
other language features added in 2.7.

Regarding dropping 3.3, every survey has shown that among the users who
have adopted py3, a vast majority are using the newest version so
supporting and testing against the older versions of 3 is not worth the
effort.

In all cases, versions of mpl that currently work on legacy versions of
python will continue to work.

Thanks to Eric, Mike, and Phil who have this a read over.

Tom

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150914/f370df22/attachment.html&gt;

3

Thomas Caswell <tcaswell at gmail.com> writes:

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)

I agree. I think for a long time the matplotlib policy was to support
the two latest Python releases, although of course there was no
deliberate effort to break earlier Pythons. Python 2 is of course a
special case, but since Python 2.7 came out in 2010, I think dropping
support for Python 2.6 should be fine in 2015.

···

--
Jouni K. Sepp?nen

4

I don't think it does undermine 2.0's philosophy of "style changes only"
as this doesn't affect the code in anyway as we don't add in any new
features in 2.0, therefore MPL-2.0 will still work fine with python-2.6,
we just won't officially support python-2.6 with version 2.0, and should
we have minor releases (2.0.1) then we don't have to worry about
py-2.6. 2.0 feels like a more appropriate place to drop it.

Best,
OceanWolf

···

On 14/09/15 22:17, Nathaniel Smith wrote:

It seems like a good idea in general to me, but doesn't it kinda
undermine the "2.0 is style changes only" idea/messaging? I assume the
maintenance burden of supporting the old versions in 2.0 won't be
large compared to 1.5 given this... Maybe 2.1 (or 1.5!) would be a
better place to draw the line?

On Sep 14, 2015 12:49 PM, "Thomas Caswell" <tcaswell at gmail.com > <mailto:tcaswell at gmail.com>> wrote:

    Hey all,

    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.

    We already support all of those versions on master, there is no
    good reason to drop 2.6 support right before the RC. For 2.0 we
    should drop 2.6 so that we do not have to maintain a mpl2.0.x
    py2.6 compatible bug-fix branch.

    Regarding dropping 2.6 as a supported version I suggest you
    read/watch the following from Nick Coghlan:

    Stop Supporting Python 2.6 (For Free) | Curious Efficiency
    http://www.pyvideo.org/video/3764/contributors-colleagues-clients-customers-su

    We are resource limited and those resources would be better spent
    improving the library and supporting modern version of python. At
    some point it is unreasonable for people running very old
    installations of python to expect the the newest versions of
    down-stream tools to work. If this is important to someone,
    please step up to mange maintaining a 1.5.x bug-fix branch which
    will maintain 2.6 compatibility.

    Dropping 2.6 will also free us to being using OrderedDict and
    several other language features added in 2.7.

    Regarding dropping 3.3, every survey has shown that among the
    users who have adopted py3, a vast majority are using the newest
    version so supporting and testing against the older versions of 3
    is not worth the effort.

    In all cases, versions of mpl that currently work on legacy
    versions of python will continue to work.

    Thanks to Eric, Mike, and Phil who have this a read over.

    Tom

    _______________________________________________
    Matplotlib-devel mailing list
    Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
    Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150915/2ca9d600/attachment.html&gt;

5

Hello,

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

···

On 14/09/15 21:49, Thomas Caswell wrote:

6

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
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150915/79f3ce57/attachment-0001.html&gt;

7

Having not heard anything back, I am going to take that as agreement :slight_smile:

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
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150926/d1e3d1b2/attachment.html&gt;

8

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 :slight_smile:

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
Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150926/575dc07e/attachment-0001.html&gt;

9

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 :slight_smile:

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
Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150927/186b8a4f/attachment.html&gt;

10

For those wondering, I think it important to add that (afaik) 2.0 will
follow very soon after 1.5, remember we only make an RC change(s)
between 2.0 and 1.5...

···

On 27/09/15 04:29, Thomas Caswell wrote:

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 > <mailto: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 > <mailto:tcaswell at gmail.com>> wrote:

        Having not heard anything back, I am going to take that as
        agreement :slight_smile:

        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 <mailto: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 <mailto: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
                <mailto:Matplotlib-devel at python.org>
                Matplotlib-devel Info Page

        _______________________________________________
        Matplotlib-devel mailing list
        Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
        Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150927/17222f98/attachment-0001.html&gt;

11

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).

I think this is a horrible idea. What is the difference between
supported and "known to work with"? For a given release to be known to
work with a give python release, it must be tested with that python
release. And it must be fixed if those tests break. Otherwise, what you
have is a release that "may work with" a given python release, but this
is not very useful to advertise.

I'm not saying that we should keep supporting python 2.6, but
introducing the concept of "known to work with" as opposed to "supported
to work with" is in my opinion a mistake.

Dropping support for old python versions is good, but please do that in
mayor releases and not in patch level releases. Breaking compatibility
in patch level releases is going to cause a lot of troubles to people
that need to support those old python releases.

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).

While I agree that those are useful features for the matplotlib API,
introducing those only for a few functions (as most of the matplotlib
API is constituted by functions imported from the same module) is going
to introduce inconsistencies (in an already quite messy API) that would
be hard to document, making the library even harder to use.

Cheers,
Daniele

···

On 15/09/15 15:20, Thomas Caswell wrote:

12

Having not heard anything back, I am going to take that as agreement :slight_smile:

I believe that taking silence as consent works only if you give a
deadline for opinions and veto before hand, not after the fact.

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

I still don't understand what "know to work with" means. From the above
it seems that it means that "you may be luck and we have not break
compatibility, but if we did, then it is on you, we are not going to fix
it". With, to me, reads the same as "not supported".

Breaking compatibility with python releases in patch version releases is
also a terrible idea, in my opinion.

Matplotlib release 1.5 is release candidate now, and as far as I know it
is supposed to work with python 2.6. What changes are you foreseeing in
patch releases of the 1.5 series that will take advantage of breaking
compatibility with python 2.6?

I believe that matplotlib 1.5 series will be only about bug fixing, and
that all development will go into 2.0. I don't really see how bug fixes
can be helped by dropping compatibility with old python releases.

As for what python releases matplotlib 2.0 should support, I don't have
strong opinions. I think dropping python 2.6 and 3.3 support may be
reasonable. However, do not change the python release support matrix in
patch level releases!

Cheers,
Daniele

···

On 26/09/15 23:29, Thomas Caswell wrote:

13

I still don't understand what "know to work with" means. From the above
it seems that it means that "you may be luck and we have not break
compatibility, but if we did, then it is on you, we are not going to fix
it". With, to me, reads the same as "not supported".

Breaking compatibility with python releases in patch version releases is
also a terrible idea, in my opinion.

Yes, this underpins the reason for changing to "known to work with...",
because we don't want to break compatibility in minor versions, but
versions 1.5 and 2.0 have already been tested thoroughly on 2.6 and 3.3.

Matplotlib release 1.5 is release candidate now, and as far as I know it
is supposed to work with python 2.6. What changes are you foreseeing in
patch releases of the 1.5 series that will take advantage of breaking
compatibility with python 2.6?

I believe that matplotlib 1.5 series will be only about bug fixing, and
that all development will go into 2.0. I don't really see how bug fixes
can be helped by dropping compatibility with old python releases.

We release 2.0 shortly after 1.5 which means 1.5 won't have any patch
fixes, and 2.0 contains no new features, but a change to the default
colours. But yes, dropping support for python 2.6 allows us use things
such as OrderedDict, not saying we will use such things in 2.0.x
(assuming we have a 2.0.x release, fingers crossed we find no bugs), but
making the change now to the requirements keeps our options open for the
future.

Best,
OceanWolf

···

On 27/09/15 14:50, Daniele Nicolodi wrote:

14

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. 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.

I very much like the second option as it is more accurate and gives _any_
support/hope to someone stuck on 2.6.

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 have already linked to this article is this thread, but once more for
good measure:

For reference, debian stable no longer has 2.6 packaged (
Python/JessieRoadmap - Debian Wiki) and RHEL has ways of getting
modern python running on older versions.

And again, as I have said at the bottom of every email, if there is someone
who really needs new features on 2.6, let me know and we will see if we can
work something out.

Tom

···

On Sun, Sep 27, 2015 at 12:31 PM OceanWolf <juichenieder-nabb at yahoo.co.uk> wrote:

On 27/09/15 14:50, Daniele Nicolodi wrote:
> I still don't understand what "know to work with" means. From the above
> it seems that it means that "you may be luck and we have not break
> compatibility, but if we did, then it is on you, we are not going to fix
> it". With, to me, reads the same as "not supported".
>
> Breaking compatibility with python releases in patch version releases is
> also a terrible idea, in my opinion.
Yes, this underpins the reason for changing to "known to work with...",
because we don't want to break compatibility in minor versions, but
versions 1.5 and 2.0 have already been tested thoroughly on 2.6 and 3.3.
> Matplotlib release 1.5 is release candidate now, and as far as I know it
> is supposed to work with python 2.6. What changes are you foreseeing in
> patch releases of the 1.5 series that will take advantage of breaking
> compatibility with python 2.6?
>
> I believe that matplotlib 1.5 series will be only about bug fixing, and
> that all development will go into 2.0. I don't really see how bug fixes
> can be helped by dropping compatibility with old python releases.
We release 2.0 shortly after 1.5 which means 1.5 won't have any patch
fixes, and 2.0 contains no new features, but a change to the default
colours. But yes, dropping support for python 2.6 allows us use things
such as OrderedDict, not saying we will use such things in 2.0.x
(assuming we have a 2.0.x release, fingers crossed we find no bugs), but
making the change now to the requirements keeps our options open for the
future.

Best,
OceanWolf
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150927/f83512f0/attachment-0001.html&gt;

15

To follow up the following is the matrix of possible 'supported python'
tables for the next few releases:

A

   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

cons: 'known to work with' is controversial/confusing, may pick up
incompatibilities on a micro release.
pros: simple on dev side, lets 2.6/3.3 semi-gracefully fall away.

B
   v1.5.0 is supported in 2.7, 3.4, 3.5
   v2.0.0 is supported in 2.7, 3.4, 3.5
   v2.0.1 is supported in 2.7, 3.4, 3.5

cons: under-documents the 'real' support, drops 2.6 without much warning
pros: simple on dev side

C
   v1.5.0 is supported in 2.6, 2.7, 3.3, 3.4, 3.5
   v2.0.0 is supported in 2.7, 3.4, 3.5
   v2.0.1 is supported in 2.7, 3.4, 3.5

cons: muddies the water on 2.0 being 'style only', under documents where
2.0 will work, implicitly commits us to a 2.6 compatible 1.5.x series but I
do not anticipate us actually doing a 1.5.x series.

My preference is A > C > B.

Tom

···

On Sun, Sep 27, 2015 at 3:49 PM Thomas Caswell <tcaswell at gmail.com> 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. 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.

I very much like the second option as it is more accurate and gives _any_
support/hope to someone stuck on 2.6.

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 have already linked to this article is this thread, but once more for
good measure:
Stop Supporting Python 2.6 (For Free) | Curious Efficiency

For reference, debian stable no longer has 2.6 packaged (
Python/JessieRoadmap - Debian Wiki) and RHEL has ways of
getting modern python running on older versions.

And again, as I have said at the bottom of every email, if there is
someone who really needs new features on 2.6, let me know and we will see
if we can work something out.

Tom

On Sun, Sep 27, 2015 at 12:31 PM OceanWolf <juichenieder-nabb at yahoo.co.uk> > wrote:

On 27/09/15 14:50, Daniele Nicolodi wrote:
> I still don't understand what "know to work with" means. From the above
> it seems that it means that "you may be luck and we have not break
> compatibility, but if we did, then it is on you, we are not going to fix
> it". With, to me, reads the same as "not supported".
>
> Breaking compatibility with python releases in patch version releases is
> also a terrible idea, in my opinion.
Yes, this underpins the reason for changing to "known to work with...",
because we don't want to break compatibility in minor versions, but
versions 1.5 and 2.0 have already been tested thoroughly on 2.6 and 3.3.
> Matplotlib release 1.5 is release candidate now, and as far as I know it
> is supposed to work with python 2.6. What changes are you foreseeing in
> patch releases of the 1.5 series that will take advantage of breaking
> compatibility with python 2.6?
>
> I believe that matplotlib 1.5 series will be only about bug fixing, and
> that all development will go into 2.0. I don't really see how bug fixes
> can be helped by dropping compatibility with old python releases.
We release 2.0 shortly after 1.5 which means 1.5 won't have any patch
fixes, and 2.0 contains no new features, but a change to the default
colours. But yes, dropping support for python 2.6 allows us use things
such as OrderedDict, not saying we will use such things in 2.0.x
(assuming we have a 2.0.x release, fingers crossed we find no bugs), but
making the change now to the requirements keeps our options open for the
future.

Best,
OceanWolf
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150927/1b5b0950/attachment.html&gt;

16

To me it just doesn't even make sense to say "2.0.0 supports py26 but 2.0.1
won't" -- "supports" means "if there's a problem, we'll fix it", and the
way you fix it is by doing a micro release, so...

It sounds like the actual policy is set (no one is willing to commit to
doing the work to keep 1.5 or 2.0 working on py26 or py33), and IMHO the
simplest way to communicate that policy to users is to just say for both
the 1.5.0 and 2.0.0:

Supported versions: 2.7, 3.4, 3.5
Other versions (esp. 2.6 and 3.3) might also work, but this is at your own
risk.

-n

···

On Sep 27, 2015 1:05 PM, "Thomas Caswell" <tcaswell at gmail.com> wrote:

To follow up the following is the matrix of possible 'supported python'
tables for the next few releases:

A

   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

cons: 'known to work with' is controversial/confusing, may pick up
incompatibilities on a micro release.
pros: simple on dev side, lets 2.6/3.3 semi-gracefully fall away.

B
   v1.5.0 is supported in 2.7, 3.4, 3.5
   v2.0.0 is supported in 2.7, 3.4, 3.5
   v2.0.1 is supported in 2.7, 3.4, 3.5

cons: under-documents the 'real' support, drops 2.6 without much warning
pros: simple on dev side

C
   v1.5.0 is supported in 2.6, 2.7, 3.3, 3.4, 3.5
   v2.0.0 is supported in 2.7, 3.4, 3.5
   v2.0.1 is supported in 2.7, 3.4, 3.5

cons: muddies the water on 2.0 being 'style only', under documents where
2.0 will work, implicitly commits us to a 2.6 compatible 1.5.x series but I
do not anticipate us actually doing a 1.5.x series.

My preference is A > C > B.

Tom

On Sun, Sep 27, 2015 at 3:49 PM Thomas Caswell <tcaswell at gmail.com> 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. 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.

I very much like the second option as it is more accurate and gives _any_
support/hope to someone stuck on 2.6.

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 have already linked to this article is this thread, but once more for
good measure:
Stop Supporting Python 2.6 (For Free) | Curious Efficiency

For reference, debian stable no longer has 2.6 packaged (
Python/JessieRoadmap - Debian Wiki) and RHEL has ways of
getting modern python running on older versions.

And again, as I have said at the bottom of every email, if there is
someone who really needs new features on 2.6, let me know and we will see
if we can work something out.

Tom

On Sun, Sep 27, 2015 at 12:31 PM OceanWolf <juichenieder-nabb at yahoo.co.uk> >> wrote:

On 27/09/15 14:50, Daniele Nicolodi wrote:
> I still don't understand what "know to work with" means. From the above
> it seems that it means that "you may be luck and we have not break
> compatibility, but if we did, then it is on you, we are not going to
fix
> it". With, to me, reads the same as "not supported".
>
> Breaking compatibility with python releases in patch version releases
is
> also a terrible idea, in my opinion.
Yes, this underpins the reason for changing to "known to work with...",
because we don't want to break compatibility in minor versions, but
versions 1.5 and 2.0 have already been tested thoroughly on 2.6 and 3.3.
> Matplotlib release 1.5 is release candidate now, and as far as I know
it
> is supposed to work with python 2.6. What changes are you foreseeing in
> patch releases of the 1.5 series that will take advantage of breaking
> compatibility with python 2.6?
>
> I believe that matplotlib 1.5 series will be only about bug fixing, and
> that all development will go into 2.0. I don't really see how bug fixes
> can be helped by dropping compatibility with old python releases.
We release 2.0 shortly after 1.5 which means 1.5 won't have any patch
fixes, and 2.0 contains no new features, but a change to the default
colours. But yes, dropping support for python 2.6 allows us use things
such as OrderedDict, not saying we will use such things in 2.0.x
(assuming we have a 2.0.x release, fingers crossed we find no bugs), but
making the change now to the requirements keeps our options open for the
future.

Best,
OceanWolf
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20150927/6336e735/attachment-0001.html&gt;

17

I agree, and prefer this over the alternatives.

Eric

···

On 2015/09/27 12:24 PM, Nathaniel Smith wrote:

and IMHO the simplest way to communicate that policy to users is to just
say for both the 1.5.0 and 2.0.0:

Supported versions: 2.7, 3.4, 3.5
Other versions (esp. 2.6 and 3.3) might also work, but this is at your
own risk.

18

I still don't understand what "know to work with" means. From the above
it seems that it means that "you may be luck and we have not break
compatibility, but if we did, then it is on you, we are not going to fix
it". With, to me, reads the same as "not supported".

Breaking compatibility with python releases in patch version releases is
also a terrible idea, in my opinion.

Yes, this underpins the reason for changing to "known to work with...",
because we don't want to break compatibility in minor versions, but
versions 1.5 and 2.0 have already been tested thoroughly on 2.6 and 3.3.

So why not state that 1.5 and 2.0 are supported on python 2.6 and 3.3?

I'm missing the point in phasing out support without a reason. It is
well tested, it works, we are not planning to introduce new
functionality, but yet we want to drop support for old python versions.
Why? I fear that the the urge of doing so is driven almost exclusively
by some guy or another writing a blog post stating that this is what
projects should do.

Matplotlib release 1.5 is release candidate now, and as far as I know it
is supposed to work with python 2.6. What changes are you foreseeing in
patch releases of the 1.5 series that will take advantage of breaking
compatibility with python 2.6?

I believe that matplotlib 1.5 series will be only about bug fixing, and
that all development will go into 2.0. I don't really see how bug fixes
can be helped by dropping compatibility with old python releases.

We release 2.0 shortly after 1.5 which means 1.5 won't have any patch
fixes, and 2.0 contains no new features, but a change to the default
colours. But yes, dropping support for python 2.6 allows us use things
such as OrderedDict, not saying we will use such things in 2.0.x
(assuming we have a 2.0.x release, fingers crossed we find no bugs), but
making the change now to the requirements keeps our options open for the
future.

I think that there is some misunderstanding. Thomas is proposing to drop
support for python versions in patch level release 2.0.1.

My understanding of a patch level release is that it only fixes bugs,
and for fixing bugs we don't need to drop support for old python version
or use newer python versions features. If you want to add features, call
it 2.1 or something.

Cheers,
Daniele

···

On 27/09/15 18:28, OceanWolf wrote:

On 27/09/15 14:50, Daniele Nicolodi wrote:

19

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:
Stop Supporting Python 2.6 (For Free) | Curious Efficiency

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

···

On 27/09/15 21:49, Thomas Caswell wrote:

20

For 1.5 it wouldn't matter much. With luck, there won't be anything
beyond 1.5.0. For 2.0 it would, because from there we will be trying to
move forward. It is easier to do that without having to maintain
backwards compatibility with old pythons.

Eric

···

On 2015/09/27 10:31 PM, Daniele Nicolodi wrote:

So why not state that 1.5 and 2.0 are supported on python 2.6 and 3.3?

I'm missing the point in phasing out support without a reason. It is
well tested, it works, we are not planning to introduce new
functionality, but yet we want to drop support for old python versions.
Why? I fear that the the urge of doing so is driven almost exclusively
by some guy or another writing a blog post stating that this is what
projects should do.