[Matplotlib-devel] Long term release schedule

[Matthias Bussonnier]

Hey Thomas,

Some comment inline,

On Mon, May 9, 2016 at 8:18 PM, Thomas Caswell <tcaswell at gmail.com> wrote:
> Folks,
>
> Compared to the short term schedule this maybe be a bit for contentious as
> it puts dropping Py2 on our road map.  This has been discussed by my self,
> Mike Droettboom, Eric Firing and Jens Nielsen.
>
> As I am sure you are all aware, upstream cpython is planning to drop support
> for python 2.7 in 2020 which leaves us in the scientific community to sort
> out how to manage this transition.   There seems to be momentum for the
> transition and we have reached the point where the discussion is not _if_ we
> drop python 2 support but _when_.
>
> The Jupyter/IPython team is working to build a community wide consensus [0]
> on moving to python3 for feature releases before 2020.  This text is still
> under development, but text has been consistent in spirit.   Instead if my
> attempting to summarize, please go read ;)
>
> We propose the following long term schedule for mpl:
>
> 2016-09/10 : 2.1
>   what we have on master is probably good enough for a release already but
> target
>   - traitlets
>   - the gui overhaul
>   if we miss them, tag in late september anyway
>
> 2017-07 : 2.2 LTS
>  - last feature release with 2.7 support
>  - critical bug fixes on mpl 2.2.x branch until 2020
>  - solicit a dedicated py2.7 maintainer
>
> 2018-07 : 3.0
>   - only support py3.4+

I wouldn't commit now to which version of Py3 you will support, It
seem to me that upgrade
of python 3 minor version seem to be a much more accepted process than fro Py2,
and 2018 is 2,5 years down the road, so by that time you might decide
to do 3.5+ only, who knows.

>   - chance to break functional API if we want
>
> This is less aggressive of a schedule than IPython (they have a planned py3
> only release at the beginning of 2017) and gives us ample time to address
> any unexpected issues in the transition.
>

We are always 3 to 6 month behind schedule, but here is the more
detailed roadmap [3]

> This plan is not with out risks (ex as master picks up python3 only code it
> will diverge from 2.2.x making back-porting bug fixes harder), however
> continuing to support python 2.7 forever has it's own.
>
> If we have users that can not (or will not) switch from py2 we are going to
> need those users to step up and support the continued maintenance of a 2.7
> compatible branch.  My personal thinking on this has been greatly influenced
> by Nick Coghlan [1], the continued support of deprecated versions of python
> for commercial use can not fall on a small group of volunteers.

I want to emphasize that if you would be interested in commercial
support by that time
(regardless of the project), it would be good to speak soon-ish, so
that companies like
continuum/enthought... can start planning for providing this support.


> As a project we have a couple of decisions to make:
>
>  1. If we adopt this as our time line (and if not what time line do we use)
>  2. If we add mpl + our time line to https://python3statement.github.io/
>
>
> [0] https://python3statement.github.io/
> [1]
> http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html

Thanks,
-- 
M

[3] https://github.com/jupyter/roadmap/blob/master/accepted/migration-to-python-3-only.md