Closed holmboe closed 2 years ago
https://github.com/ssato/python-anyconfig/blob/master/NEWS
Some hints by running git log RELEASE_0.10.1.. -p
in the ssato/python-anyconfig source.
Do this newer version of any config work with python 2.7? Also any major changes between 0.10 and 0.11 that would make >=0.11 more suitable to use?
- change: drop python 2.x support
This was added in 0.10 and it will break out compatibility in this tool for python 2.7
Do this newer version of any config work with python 2.7? Also any major changes between 0.10 and 0.11 that would make >=0.11 more suitable to use?
I have only focused on this API change and verified that it was breaking starting with 0.10.0. Changes other than the API incompatibility is out of scope for this bug and therefore not investigated further.
- change: drop python 2.x support
This was added in 0.10 and it will break out compatibility in this tool for python 2.7
I guess that we are fine with dropping Python 2.7 support? I will update the PR to reflect this.
@holmboe Yes we are kinda fine with dropping python support. The main thing would be that we need to make a new major release out of it. Also i would suggest that you drop at least 3.6 as well as many new features comes in at 3.7. In reality we should follow the old golden rule of python support, "latest major version and two major versions back", but in this instance i am fine with 3.7-3.10 really.
@Grokzen My take on that is that we should support whatever Python version is in current Ubuntu LTS and the one before it.
Ubuntu 22.04 LTS is just around the corner so it should be fine for us to drop 18.04 and Python 3.6. As far as my above reasoning goes I am fine with supporting 3.8 and above.
@Grokzen My take on that is that we should support whatever Python version is in current Ubuntu LTS and the one before it.
- Ubuntu 18.04 LTS (bionic), Python 3.6
- Ubuntu 20.04 LTS (focal), Python 3.8
Ubuntu 22.04 LTS is just around the corner so it should be fine for us to drop 18.04 and Python 3.6. As far as my above reasoning goes I am fine with supporting 3.8 and above.
Yeah, we need to agree on a standard for this i guess. I am not in favor really to just base our support levels on Ubuntu version ranges because we then limit our self in all other distros including all windows versions that do not have any specific version bundled with it. But you also have the python EOL way of doing it where we should only support the same versions they do for instance, and the ubuntu support version as well, so we have several competing standards here really to consider
Yeah, we need to agree on a standard for this i guess. I am not in favor really to just base our support levels on Ubuntu version ranges because we then limit our self in all other distros including all windows versions that do not have any specific version bundled with it. But you also have the python EOL way of doing it where we should only support the same versions they do for instance, and the ubuntu support version as well, so we have several competing standards here really to consider
Even though python.org has them EOL:ed, Ubuntu takes on maintenance of the Python versions that they ship in their LTS releases. So realistically those versions are very much in active use.
We want the tools to be practically usable on the Linux distributions which is commonly used.
Yeah, we need to agree on a standard for this i guess. I am not in favor really to just base our support levels on Ubuntu version ranges because we then limit our self in all other distros including all windows versions that do not have any specific version bundled with it. But you also have the python EOL way of doing it where we should only support the same versions they do for instance, and the ubuntu support version as well, so we have several competing standards here really to consider
Even though python.org has them EOL:ed, Ubuntu takes on maintenance of the Python versions that they ship in their LTS releases. So realistically those versions are very much in active use.
We want the tools to be practically usable on the Linux distributions which is commonly used.
I guess you can also add in one argument that the python package itself should be fully standalone from any packaging dependencies or requirements for each individual system that it might be used on. For instance if we would package this as a RPM/DEB/Windows package they could take care of and require certain versions of any dependency python or whatnot and the base package has their own rules.
Fixes #39