i'll start my testing w/3.6 tomorrow.

On Mon, Aug 20, 2018 at 1:30 PM, Li Jin <ice.xell...@gmail.com> wrote:

> Thanks for looking into this Shane. If we can only have a single python 3
> version, I agree 3.6 would be better than 3.5. Otherwise, ideally I think
> it would be nice to test all supported 3.x versions (latest micros should
> be fine).
>
> On Mon, Aug 20, 2018 at 7:07 PM shane knapp <skn...@berkeley.edu> wrote:
>
>> initially, i'd like to just choose one version to have the primary tests
>> against, but i'm also not opposed to supporting more of a matrix.  the
>> biggest problem i see w/this approach, however, is that of build monitoring
>> and long-term ownership.  this is why we have a relatively restrictive
>> current deployment.
>>
>> another thing i've been noticing during this project is that we have a
>> lot of flaky tests...  for instance, i'm literally having every other build
>> fail on my (relatively) up-to-date PRB fork:
>> https://amplab.cs.berkeley.edu/jenkins/job/ubuntuSparkPRB/
>>
>> (i'm testing more than python here, otherwise i could just build a spark
>> distro and run the python tests against that)
>>
>> i'll also set up a 3.6 env tomorrow and start testing against that.  i'm
>> pretty confident about 3.5, tho.
>>
>> shane
>>
>> On Mon, Aug 20, 2018 at 11:33 AM, Bryan Cutler <cutl...@gmail.com> wrote:
>>
>>> Thanks for looking into this Shane!  If we are choosing a single python
>>> 3.x, I think 3.6 would be good. It might still be nice to test against
>>> other versions too, so we can catch any issues. Is it possible to have more
>>> exhaustive testing as part of a nightly or scheduled build? As a point of
>>> reference for Python 3.6, Arrow is using this version for CI.
>>>
>>> Bryan
>>>
>>> On Sun, Aug 19, 2018 at 9:49 PM Hyukjin Kwon <gurwls...@gmail.com>
>>> wrote:
>>>
>>>> Actually Python 3.7 is released (https://www.python.org/
>>>> downloads/release/python-370/) too and I fixed the compatibility
>>>> issues accordingly - https://github.com/apache/spark/pull/21714
>>>> There has been an issue for 3.6 (comparing to lower versions of Python
>>>> including 3.5) - https://github.com/apache/spark/pull/16429
>>>>
>>>> I am not yet sure what's the best matrix for it actually. In case of R,
>>>> we test lowest version in Jenkins and highest version via AppVeyor FWIW.
>>>> I don't have a strong preference opinion on this since we have been
>>>> having compatibility issues for each Python version.
>>>>
>>>>
>>>> 2018년 8월 14일 (화) 오전 4:15, shane knapp <skn...@berkeley.edu>님이 작성:
>>>>
>>>>> hey everyone!
>>>>>
>>>>> i was checking out the EOL/release cycle for python 3.5 and it looks
>>>>> like we'll have 3.5.6 released in early 2019.
>>>>>
>>>>> this got me to thinking:  instead of 3.5, what about 3.6?
>>>>>
>>>>> i looked around, and according to the 'docs' and 'collective wisdom of
>>>>> the internets', 3.5 and 3.6 should be fully backwards-compatible w/3.4.
>>>>>
>>>>> of course, this needs to be taken w/a grain of salt, as we're mostly
>>>>> focused on actual python package requirements, rather than worrying about
>>>>> core python functionality.
>>>>>
>>>>> thoughts?  comments?
>>>>>
>>>>> thanks in advance,
>>>>>
>>>>> shane
>>>>> --
>>>>> Shane Knapp
>>>>> UC Berkeley EECS Research / RISELab Staff Technical Lead
>>>>> https://rise.cs.berkeley.edu
>>>>>
>>>>
>>
>>
>> --
>> Shane Knapp
>> UC Berkeley EECS Research / RISELab Staff Technical Lead
>> https://rise.cs.berkeley.edu
>>
>


-- 
Shane Knapp
UC Berkeley EECS Research / RISELab Staff Technical Lead
https://rise.cs.berkeley.edu

Reply via email to