I think as long as we have an easy docker-compose Python 2 build we can run nightly or ad hoc Python 2.7 builds. Running such builds should be part of getting ready for a release, anyway. Hopefully the Ursa Labs build cluster will be operational in the near future and can help with automating this.
I'm in favor of dropping 2.7 from CI as long as we incorporate a 2.7 check into the release process. It will certainly help alleviate CI runtimes On Thu, May 30, 2019 at 12:34 PM Uwe L. Korn <uw...@xhochy.com> wrote: > > Hello Antoine, > > when we're not testing Python 2.7 on CI anymore, I would suggest to drop > Python 2 support completely then. My personal experience tells me that once > we drop Python 2 on CI, we will immediately build a simple thing that breaks > Python 2 support. > > Pushing out releases that might work for Python 2 but in the end won't do > will make Arrow users more frustrated than just dropping support for it. In > addition, we would also have to deal with a lot of user reports when we break > it, explicitly dropping Py2 would just mean that a "python2 -m pip install > pyarrow" will leave them with an old but functioning version. > > Regards > Uwe > > On Thu, May 30, 2019, at 4:15 PM, Antoine Pitrou wrote: > > > > Hello, > > > > Python 2.7 will soon be end-of-life. It will stop being supported > > upstream on January 1st, 2020. Many projects have started publishing > > Python 3-only releases (see https://python3statement.org/). > > > > PyArrow will soon stop supporting Python 2 as well, perhaps at the end > > of the year. > > > > In the meantime, as build times on public Continuous Integration > > services have continuously ballooned, we could start by not testing > > Python 2 anymore on those services. It would easy build times a bit. > > Testing would be done as a best effort thing, possibly by users of > > development versions. > > > > Regards > > > > Antoine. > > > > > >
