Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upDrop support for EOL Python 2.6 and 3.3 #737
Conversation
|
Thank you so much for this massive cleanup! I will have a closer look in the following days, and invite @yarikoptic and @ankostis to do the same. What do you all think how this change should be released? In theory it would have to be a major version jump, as we might break some people. On the other hand, the API didn't change so the release might be confusing and repelling to everyone else. From that point of view, it might not be more than a patch release. |
|
You're welcome, and thanks for the maintenance! Some projects bump major versions to indicate dropping support, some don't. If following semver, it depends if you consider it a backwards incompatible changes:
https://semver.org/#spec-item-8 I probably would bump it, but don't have strong opinions. It's good 2.1.8 was already released with |
|
Looks good to me! |
|
And since we don't change the public API in that sense, I think a major version bump shouldn't be required. Also I would rather upset those behind ~1000 downloads, rather than confusing (or loosing) those behind the 500k downloads. I will wait a week for more commends and/or opinions to come in, and if there are no objects, will release a new version next weekend. |
|
cute! just 2 minor comments/questions ;) |
| * `[include]` sections in git configuration files are now respected | ||
| * Added `GitConfigParser.rename_section()` | ||
| * Added `Submodule.rename()` | ||
| * A list of all issues can be found `on github <https://github.com/gitpython-developers/GitPython/issues?q=milestone%3A%22v0.3.6+-+Features%22+>`_ | ||
| * A list of all issues can be found `on GitHub <https://github.com/gitpython-developers/GitPython/issues?q=milestone%3A%22v0.3.6+-+Features%22+>`_ |
yarikoptic
Mar 19, 2018
Collaborator
Probably could/will be added later -- but there should be a "loud" changelog entry about dropping 2.6 support for the upcoming release
Probably could/will be added later -- but there should be a "loud" changelog entry about dropping 2.6 support for the upcoming release
hugovk
Mar 19, 2018
Author
Contributor
Yes, that would be sensible.
Would you like me to do that as part of this PR, or should it wait? If now, what's version will the next release be?
Yes, that would be sensible.
Would you like me to do that as part of this PR, or should it wait? If now, what's version will the next release be?
| @@ -3,4 +3,4 @@ | |||
| coverage | |||
| flake8 | |||
| nose | |||
| mock; python_version<='2.7' | |||
| mock; python_version=='2.7' | |||
yarikoptic
Mar 19, 2018
Collaborator
so version here could never include ".patch" (ie to be 2.7.5)? if it could then would need to retain <=
so version here could never include ".patch" (ie to be 2.7.5)? if it could then would need to retain <=
hugovk
Mar 19, 2018
Author
Contributor
Not too sure. Shall I revert this to be on the safe side?
Not too sure. Shall I revert this to be on the safe side?
Codecov Report
@@ Coverage Diff @@
## master #737 +/- ##
==========================================
- Coverage 94.66% 94.66% -0.01%
==========================================
Files 60 59 -1
Lines 9338 9289 -49
==========================================
- Hits 8840 8793 -47
+ Misses 498 496 -2
Continue to review full report at Codecov.
|
As a follow on from #540 (comment), this drops support for Python 2.6 and 3.3, both of which are EOL and no longer receiving security updates, or any updates, from the core Python team.
They're also little used. Here's the pip installs for GitPython from PyPI for last month:
Source:
pypinfo --start-date -39 --end-date -12 --percent --pip --markdown GitPython pyversionDropping Python 2.6 means some old compatibility and 2.6-specific code can be removed, and can also be updated to use more modern features of Python 2.7+, some of which has been applied here.
Python 3.3 is also dropped here. Whilst there's less benefit to be had from code changes (compared to 2.6), it's unsupported and used even less that 2.6 (in this project and in general), so there's no strong reason to keep it and we might as well free up some CI slots.