Skip to content
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
Closed

Support 3.4 runtime (and others) #95

ooq opened this issue Mar 18, 2017 · 5 comments
Assignees
Labels
Milestone

Comments

@ooq
Copy link
Collaborator

@ooq 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
Copy link
Collaborator

@shivaram 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
Copy link
Collaborator

@ericmjonas 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
Copy link
Collaborator

@ericmjonas 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
Copy link
Collaborator Author

@ooq 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
Copy link
Collaborator

@ericmjonas 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.