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
-
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