supported python versions

daniele1 · September 28, 2015, 9:02am

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

Unfortunately, this is only a partial matrix, and as Nathaniel pointed
out is not self-consistent: supported means that we fix bugs and release
patched version, if the patched version does not maintain compatibility
promises we are breaking support.

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.

Usually people votes on alternative proposals once all the different
options are laid down and agreed upon. I would like to add:

D
     v1.5 is supported in 2.6, 2.7, 3.3, 3.4, 3.5 (status quo)
     v2.0 is supported in 2.6, 2.7, 3.3, 3.4, 3.5 (status quo)
     v2.1 is supported in 2.7, 3.4, 3.5

This is with the assumption that v1.5.x bugfix releases happen only if
mayor bugs that make it unusable are found in 1.5, and v2.0.x bugfix
releases happen until 2.1 is released. 2.0 differs from 1.5 only for the
default styles, that (I believe) can be set to the 1.5 ones via
configuration parameters, thus the ones that require extended support
for the 1.5 series can simply grab the 2.0.x releases and modify the
default settings.

pros: keeps promises, easy to communicate and understand
cons: one bugfix only branch needs to be maintained

Cheers,
Daniele

···

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

thomas.robitaille · September 28, 2015, 11:58am

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

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

ben.v.root · September 28, 2015, 1:28pm

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:

.py in the sky

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:
>>
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
>
> _______________________________________________
> 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/20150928/c4d2f38e/attachment.html>

tacaswell · October 8, 2015, 7:52pm

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] TST: drop py2.6 & py3.3 testing by tacaswell · Pull Request #5215 · matplotlib/matplotlib · GitHub

···

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:

.py in the sky

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

_______________________________________________
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/20151008/80eefc16/attachment.html>

njs · October 8, 2015, 7:57pm

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> 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] TST: drop py2.6 & py3.3 testing by tacaswell · Pull Request #5215 · matplotlib/matplotlib · GitHub

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:

.py in the sky

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

_______________________________________________
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/20151008/d78d6267/attachment-0001.html>

tacaswell · October 8, 2015, 8:12pm

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> 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> 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] TST: drop py2.6 & py3.3 testing by tacaswell · Pull Request #5215 · matplotlib/matplotlib · GitHub

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:

.py in the sky

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

_______________________________________________
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/20151008/4e4e5dd1/attachment.html>

nathan12343 · October 8, 2015, 8:16pm

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] TST: drop py2.6 & py3.3 testing by tacaswell · Pull Request #5215 · matplotlib/matplotlib · GitHub

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:

.py in the sky

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:
>>
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
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
<javascript:_e(%7B%7D,'cvml','Matplotlib-devel at python.org');>
> Matplotlib-devel Info Page
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
<javascript:_e(%7B%7D,'cvml','Matplotlib-devel at python.org');>
Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
<javascript:_e(%7B%7D,'cvml','Matplotlib-devel at python.org');>
Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
<javascript:_e(%7B%7D,'cvml','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/20151008/0663cd31/attachment-0001.html>

ariza.federico · October 8, 2015, 8:21pm

It may sound stupid.

If I introduce an OrderedDict to replace an ugly list of lists in
ToolManager (change that I wanted to do for a long time)

The problem will be automatically solved. No more 2.6 that's it that's all

···

On 8 Oct 2015 4:16 pm, "Nathan Goldbaum" <nathan12343 at gmail.com> wrote:

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> 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> 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] TST: drop py2.6 & py3.3 testing by tacaswell · Pull Request #5215 · matplotlib/matplotlib · GitHub

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:

.py in the sky

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

_______________________________________________
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

_______________________________________________
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/20151008/4b625413/attachment.html>

njs · October 8, 2015, 10:57pm

Clarity is nine-tenths of grace

···

On Oct 8, 2015 1:13 PM, "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> 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> 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] TST: drop py2.6 & py3.3 testing by tacaswell · Pull Request #5215 · matplotlib/matplotlib · GitHub

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:

.py in the sky

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

_______________________________________________
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/20151008/90069205/attachment-0001.html>

juichenieder-nabb · October 8, 2015, 11:22pm

I think it possible for anyone to misinterpret whatever we say, making
it clear to 100% of people will become impossible. Otherwise we just
end up bikeshedding. After all, all this effort over wording etcetera
can only benefit py2.6 users, so do we deem that worth the effort?
Those 2.6 users who don't understand and don't try to understand and get
annoyed at us for not understanding when we tried to tell them that they
use outdated software and should update.

Anyway, for wording how about:
"As of matplotlib2 we no longer support python2.6, (parts of) matplotlib
may still continue to work with python2.6, but you should treat this as
luck and not as by design."

With Tom having the final say so as to avoid this bikeshedding...

···

On 09/10/15 00:57, Nathaniel Smith wrote:

Clarity is nine-tenths of grace

On Oct 8, 2015 1:13 PM, "Thomas Caswell" <tcaswell at gmail.com > <mailto: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 > <mailto: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 > <mailto: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] TST: drop py2.6 & py3.3 testing by tacaswell · Pull Request #5215 · matplotlib/matplotlib · GitHub

            On Mon, Sep 28, 2015 at 9:29 AM Benjamin Root > <ben.v.root at gmail.com <mailto: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 > <mailto: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:

                    .py in the sky

                    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:
                    >>
                    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
                    >
                    > _______________________________________________
                    > 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
                <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/20151009/a5f5c3b6/attachment-0001.html>