New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support 3.4 runtime (and others) #95

Closed
ooq opened this Issue Mar 18, 2017 · 5 comments

Comments

Projects
None yet
3 participants
@ooq
Collaborator

ooq commented Mar 18, 2017

We have users with python 3.4. Should we build and upload 3.4 runtime? and other python versions?

@ooq ooq added the firstcamp label Mar 18, 2017

@shivaram

This comment has been minimized.

Show comment
Hide comment
@shivaram

shivaram Mar 18, 2017

Collaborator

Is it the pickling / serialization that is sensitive to even minor version changes in Python ? I think adding 3.4 might be fine as it is probably in the top-3 of versions used (see https://hynek.me/articles/python3-2016 for example), but maintaining more versions does make testing etc. more expensive

Collaborator

shivaram commented Mar 18, 2017

Is it the pickling / serialization that is sensitive to even minor version changes in Python ? I think adding 3.4 might be fine as it is probably in the top-3 of versions used (see https://hynek.me/articles/python3-2016 for example), but maintaining more versions does make testing etc. more expensive

@ericmjonas

This comment has been minimized.

Show comment
Hide comment
@ericmjonas

ericmjonas Mar 18, 2017

Collaborator

I think it's easier for most of the users we care about to make them upgrade to 3.x then try and support an additional runtime. Runtime builds already take too long.

Collaborator

ericmjonas commented Mar 18, 2017

I think it's easier for most of the users we care about to make them upgrade to 3.x then try and support an additional runtime. Runtime builds already take too long.

@ericmjonas

This comment has been minimized.

Show comment
Hide comment
@ericmjonas

ericmjonas Mar 22, 2017

Collaborator

The other issue here is that we don't want to increase our test runtime by 33%

Collaborator

ericmjonas commented Mar 22, 2017

The other issue here is that we don't want to increase our test runtime by 33%

@ericmjonas ericmjonas modified the milestone: v0.3 Mar 22, 2017

@ooq

This comment has been minimized.

Show comment
Hide comment
@ooq

ooq Mar 22, 2017

Collaborator

Agree on that testing is one huge concern here.
However, I still don't want to have nightmares of those 3.4 users struggling and suffering.
One potential solution I'm thinking, is that can we:
1, only test 2.6 and 3.6 for development -- this even reduces our current testing time
2, testing all sub-versions for releases

The hope here is that differences between subversion should be small and easy to fix.

Collaborator

ooq commented Mar 22, 2017

Agree on that testing is one huge concern here.
However, I still don't want to have nightmares of those 3.4 users struggling and suffering.
One potential solution I'm thinking, is that can we:
1, only test 2.6 and 3.6 for development -- this even reduces our current testing time
2, testing all sub-versions for releases

The hope here is that differences between subversion should be small and easy to fix.

@ericmjonas

This comment has been minimized.

Show comment
Hide comment
@ericmjonas

ericmjonas Aug 31, 2017

Collaborator

I'm going to mark this closed given that we now 1. bail on setup.py if we have less than 3.4 and 2. have 3.4 runtimes deployed to the new runtime location

Collaborator

ericmjonas commented Aug 31, 2017

I'm going to mark this closed given that we now 1. bail on setup.py if we have less than 3.4 and 2. have 3.4 runtimes deployed to the new runtime location

@ericmjonas ericmjonas closed this Aug 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment