Skip to content

Support for Python 2.6 not stated #453

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

Closed
andy-maier opened this issue May 30, 2016 · 3 comments
Closed

Support for Python 2.6 not stated #453

andy-maier opened this issue May 30, 2016 · 3 comments

Comments

@andy-maier
Copy link
Contributor

I am maintaining a project that still supports Python 2.6, and I was glad to see that commit 9989f89 added a workaround for OrderedDict in support of Python 2.6.

However, the PyPI package information of GitPython 2.0.3 does not mention Python 2.6.

I would very much see the support for Python 2.6 in this package continued, as long as it can reasonably be maintained, and I suggest to add Python 2.6 to the package metadata. Probably it would be good to also state (maybe in the package description text that appears on PyPI) that the Python 2.6 support is on a best-can-do basis only.

@Byron
Copy link
Member

Byron commented May 30, 2016

What I could easily do is to add this information to the pypi package text, even though I am not sure that it will be read. The README also has no information about that either just yet.

About pypi, I totally see your point, and was thinking about adding py2.6 to it myself, yet came to the conclusion that this only allows to indicate 100% compatibility. It could also be read by tools which make the wrong conclusions. What do you think about this objection ?

@andy-maier
Copy link
Contributor Author

I thought about your argument, and I still think the PyPI metadata for 2.6 should be added, as long as it seems to work on 2.6. In case some unsurmountable problem occurs on 2.6, (or even if a problem occurs that could be solved but that you don't want to solve anymore), then you can make the decision at that point to drop support for 2.6 and you can remove the metadata tag for 2.6 again in a release update.

If tools parse the metadata tag as long as it is on a release, they conclude the package can be used on 2.6, which is what you want to express with it.

I think the real concern is the unknowns of potential future problems, and whether they can be solved if they occur. My take there is simply as long as you don't know of any problems, it works. And you can only tell whether a problem can be solved or not when it has occurred.

@Byron
Copy link
Member

Byron commented Jun 1, 2016

@andy-maier Thanks a bunch for your argumentation - I like the idea of stating the intend, while waiting for people posting their issues. Will make the respective change in a moment.

@Byron Byron added this to the v2.0.6 - Bugfixes milestone Jun 1, 2016
@Byron Byron closed this as completed in 543d900 Jun 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants