Replies: 2 comments 1 reply
-
I think this is a very sensible plan. If there's a route to using a legacy version of GPy with older python, then that should ensure those that can't upgrade still have access. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Nobody's complained here, so I'd levy we're clear to drop 3.5 support. The remaining question is: how do we want to document the last version with Python x.y.z support? I'd say the wiki here is a good first pass, and anything more heavyweight can be added iteratively later - how does that sound? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
To keep the maintenance effort slim and encourage use of recent Python language features, I'm suggesting we drop Python 3.5. Also, it seems prudent to keep a record of the latest version with Python X.Y support for all X.Y so e.g. someone who requires legacy support for a dependent project can easily find which
pip install GPy==1.A.B
version they should install in the wiki.Is there an existing policy for how to add or remove support for Python versions? Or a strong reason to keep 3.5 support?
Beta Was this translation helpful? Give feedback.
All reactions