In Numpy they are considering dropping 3.5 support for 1.18 or 1.19. P.
On Tue, Nov 5, 2019 at 11:15 PM Xingjian SHI <xsh...@connect.ust.hk> wrote: > I don’t think we should drop Python 3.5 now because Ubuntu 16.04 ships > with that version. I suggest that we should revisit it next year. > > Best, > Xingjian > ________________________________ > From: Sheng Zha <zhash...@apache.org> > Sent: Tuesday, August 27, 2019 10:49 AM > To: d...@mxnet.apache.org > Subject: Re: [Discuss] MXNet Python < 3.6 Support Deprecation > > Good summary. At the start the discussion thread my ask is to announce the > intention of py2 deprecation in the next release, and then actually > deprecate py2 in the next major release. Thus, the appropriate timing for > dropping py2 support in CI should be the start of the next major release. > The py35 vs py36 discussion will not affect the outcome of py2 deprecation. > > BTW, one alternative option to a formal voting in the Apache way is to > through lazy consensus [1], which could apply more in our project. Given > the positive feedback in this discussion thread, I will assume lazy > consensus in 72hrs on py2 deprecation as defined above. > > [1] https://community.apache.org/committers/lazyConsensus.html > > On 2019/08/27 00:19:14, Marco de Abreu <marco.g.ab...@gmail.com> wrote: > > Pedro, > > > > thanks for already starting these efforts, but it might be too early for > > that. Right now, this is a discussion thread where we try to gather > > different opinions in order to lay a good base for a future voting > thread. > > In there, we would define the detailed timeline, versions etc. Until the > > vote has passed, I'd say that it's too early to draw any conclusions. So > > far, there are two open discussion points: > > > > 1. Which Python version to support. 3.5 vs 3.6 is currently in the > > discussion due to Ubuntu 16.04 being shipped with 3.5 while the biggest > > market share being 3.6 as of now. > > 2. When to do the deprecation. EOY to match with official Python 2 > > deprecation, in 1.5 years to be in line with Ubuntu 16.04 LTS or with the > > next major release (2.0) to adhere to semantic versioning. > > > > Once these points (and any future ones) have been properly discussed and > > the community came to an agreement, we can formalize it with a voting > > thread. Until then, I'd recommend to refrain from any actions or > > user-facing communication regarding this topic. > > > > Best regards, > > Marco > > > > On Tue, Aug 27, 2019 at 1:29 AM Pedro Larroy < > pedro.larroy.li...@gmail.com> > > wrote: > > > > > I have sent a PR that removes Python2 from CI. But was closed. I > thought > > > everyone was +1 on this one. This would remove quite a bit of load on > CI: > > > > > > https://github.com/apache/incubator-mxnet/pull/15990 > > > > > > If it's not the right time to do this, what steps do we need to take? > > > > > > Pedro. > > > > > > > > > On Mon, Aug 26, 2019 at 1:27 AM Leonard Lausen <leon...@lausen.nl> > wrote: > > > > > > > Lieven Govaerts <l...@apache.org> writes: > > > > > Hi, > > > > > > > > > > On Thu, 22 Aug 2019 at 17:01, Leonard Lausen <leon...@lausen.nl> > > > wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> Pedro stated "Seems 3.6 is a reasonable choice." and there have > been a > > > > >> few +1 after Chaitanya's reply to Pedro. I would like to check if > > > these > > > > >> only refer to Chaitanya's mail about a dedicated "improvement" > effort > > > or > > > > >> about dropping 3.5. > > > > >> > > > > >> Thus two questions: > > > > >> > > > > >> 1) Are there any concerns about dropping Python 3.5? Now is your > > > chance > > > > to > > > > >> speak up if you think so. > > > > >> > > > > >> > > > > > Ubuntu 16.04 LTS defaults to Python 3.5.x . The LTS releases are > > > > supported > > > > > for 5 years, so for 16.04 LTS it ends in 1.5 years. > > > > > > > > > > I'm not saying you should wait for 1.5 more years, people can > upgrade > > > to > > > > > 18.04 LTS after all, but may I suggest you make this switch in a > major > > > > > release only? More specifically, ensure that Python 3.6-only code > > > doesn't > > > > > accidentally gets merged into a 1.5.X patch release. > > > > > > > > > > thanks, > > > > > > > > > > Lieven > > > > > > > > Hi Lieven, > > > > > > > > thanks. I believe the Python version compatibility falls under the > > > > semantic versioning umbrella of things not to break within any 1.x > > > > release. Thus above suggestion would be with respect to a 2.x > release or > > > > experimental / preview / new features added to 1.x, without affecting > > > > existing 1.x features. It would not affect 1.5.x patch releases. > > > > > > > > Best regards, > > > > Leonard > > > > > > > > > > > > >> 2) Should new MXNet 1.x (experimental?) functionality (for example > > > numpy > > > > >> compatible interface) only target the Python versions to be > supported > > > in > > > > >> MXNet 2? The current plan is to make many MXNet 2 features > available > > > as > > > > >> "opt-in" in MXNet 1.x. Supporting older Python versions on MXNet > 1 for > > > > >> these features may impact design and functionality and create > > > > >> unnecessary technical debt. > > > > > > > > > >
