It would be good to test all Python versions in a cron build, but I agree we may not need to test all Python 3 versions in per-commit builds.
Regards Antoine. Le 07/08/2018 à 03:14, Robert Nishihara a écrit : > Thanks Wes. > > As for Python 3.5, 3.6, and 3.7, I think testing any one of them should be > sufficient (I can't recall any errors that happened with one version and > not the other). > > On Mon, Aug 6, 2018 at 12:01 PM Wes McKinney <wesmck...@gmail.com> wrote: > >> @Robert, it looks like NumPy is making LTS releases until Jan 1, 2020 >> >> >> https://docs.scipy.org/doc/numpy-1.14.0/neps/dropping-python2.7-proposal.html >> >> Based on this, I think it's fine for us to continue to support Python >> 2.7 until then. It's only 16 months away; are you all ready for the >> next decade? >> >> We should also discuss if we want to continue to build and test Python >> 3.5. From download statistics it appears that there are 5-10x as many >> Python 3.6 users as 3.5. I would prefer to drop 3.5 and begin >> supporting 3.7 soon. >> >> @Antoine, I think we can avoid building the C++ codebase 3 times, but >> it will require a bit of retooling of the scripts. The reason that >> ccache isn't working properly is probably because the Python include >> directory is being included even for compilation units that do not use >> the Python C API. >> https://github.com/apache/arrow/blob/master/cpp/CMakeLists.txt#L721. >> I'm opening a JIRA about fixing this >> https://issues.apache.org/jira/browse/ARROW-2994 >> >> Created https://issues.apache.org/jira/browse/ARROW-2995 about >> removing the redundant build cycle >> >> On Mon, Aug 6, 2018 at 2:19 PM, Robert Nishihara >> <robertnishih...@gmail.com> wrote: >>>> >>>> Also, at this point we're sometimes hitting the 50 minutes time limit on >>>> our slowest Travis-CI matrix job, which means we have to restart it... >>>> making the build even slower. >>>> >>> Only a short-term fix, but Travis can lengthen the max build time if you >>> email them and ask them to. >> >
