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

Drop support for python 2 #578

Closed
tpazderka opened this issue Nov 16, 2018 · 9 comments
Closed

Drop support for python 2 #578

tpazderka opened this issue Nov 16, 2018 · 9 comments
Assignees
Milestone

Comments

@tpazderka
Copy link
Collaborator

I think that it is about time we drop support for python 2. The remaining lifetime is only one year and dropping this support would allow some much needed code cleanup.

We should do a last release which would support both versions of python towards the end of the year and then drop python 2 entirely in 2019.

If we agree on this, I can focus on that.

@schlenk
Copy link
Collaborator

schlenk commented Nov 16, 2018

Technically, I'm sitting on a Python 2 codebase for a while still (the joy of huge legacy codebases). And will be migrating to Python 3 during the next year. So i would prefer to keep things useable for both for that time for reasons.

But i agree that it is a reasonable goal to drop Python 2 support.

@fredrikstormo
Copy link

Another option is to fork out the Python 2 support into a separate project.

@tpazderka
Copy link
Collaborator Author

Technically, I'm sitting on a Python 2 codebase for a while still (the joy of huge legacy codebases). And will be migrating to Python 3 during the next year. So i would prefer to keep things useable for both for that time for reasons.

But i agree that it is a reasonable goal to drop Python 2 support.

Technically, you can run on the latest supported release :) The release cycle has slowed down recently so I think that you should be able to stay on that release for the next year without much trouble.

Another option is to fork out the Python 2 support into a separate project.

I would rather not fork as it would create quite a lot of overhead.

@schlenk
Copy link
Collaborator

schlenk commented Nov 16, 2018

I also think a fork is a bad idea.

I just think end-of-year is a little to aggressive.

Imagine you are using pyoidc as an authentication system in a Python 2.7 based system. So you want to be able to update to new releases quickly, in case of security issues. It is even mandatory for some people to be able to do that. Now we drop Python 2.7 support for end of year with an effectively 4 week timeframe (christmas, new year etc.) for people to upgrade their setup to Python 3.x.

So either we at least have plans do some kind of security only releases for the 2.7 based stuff for a while (when needed), or we should make the full switch later (e.g. 1. April 2019, 1. July, etc.).

So I would be fine with creating a branch for the old 2.7 stuff with 'security fixes only' and a branch for new development, features etc.

@tpazderka
Copy link
Collaborator Author

I meant we do a release toward the end of the year that has all the current features and still supports 2.7.
And then start working on droping the 2.7 support. That would probable mean to release 3.x version sometime in spring?

@schlenk
Copy link
Collaborator

schlenk commented Nov 16, 2018

Sounds like a reasonable plan, yes.

@tpazderka
Copy link
Collaborator Author

tpazderka commented Nov 16, 2018

OK then, lets do a release in January, so we don't release before Christmas and then we can start working on droping Py2 support :)

@schlenk
Copy link
Collaborator

schlenk commented Nov 16, 2018

Guess you meant drop Py2 support ;-).

@tpazderka
Copy link
Collaborator Author

Yep!

@tpazderka tpazderka added this to the 1.0 milestone Jan 14, 2019
@tpazderka tpazderka mentioned this issue Jan 24, 2019
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants