Remove support for python 3.7 and possibly other older versions

[amimas]

This project is currently tested using several versions of python:

• 3.7
• 3.8
• 3.9
• 3.10
• 3.11

According to status of python versions, version 3.7 is already end-of-life. I don't think there's any point in testing the project in that version of python. I think we should remove this version's tests from the CI.

As for version 3.8 - 3.10, they are also not in active development state. Only security releases will be available. Should we define a smaller matrix of older versions of python to be supported? Do we need to support that many versions of python? Not sure if I missed the reason in the docs. Maybe currently supported version and one previous version is good enough? 🤷

[gdubicki]

Hey!

Historically gitlabform was used in some places as a library and sometime the code was running in places where only pretty old versions of Python were available.

However using gitlabform as a library is not supported anymore so I think we could drop do what you propose, @amimas, and support only the current and previous version of Python.

Of course we would need to release gitlabform v4 for that as it is a backward-incompatible change, but it's not a problem.

[amimas]

Hey @gdubicki - Thanks for the context. You're right that it'll be backward-incompatible change. Unless we have active v4 developments in plan, let's put it on hold. I don't think it's worth doing a major release just for this. Plus running those old version of python tests in GitHub Actions is not causing a big problem as far as I know.

So, let's hold off on this for now. I'll add a label so that we can pick this up if/when v4 work takes place.

[amimas]

Looking at the above related PRs, it seems others are dropping support for Python 3.7 without doing a major release.

This got me curious. Found an article on this topic that gives argument for dropping language support can be a minor release (i.e. public api for last supported version isn't changing).

https://medium.com/@sampart/semantic-versioning-when-you-change-the-required-programming-language-version-16a3a3555c95

There's also a discussion ongoing in the semvar project on this topic. Couldn't finish reading through the entire thread though 😓

semver/semver#716

Right now I'm inclined towards a minor version release of gitlabform for this issue :)

[gdubicki]

I originally adapted the approach to bump the major version in this case from voxpupuli's projects, https://github.com/voxpupuli/puppetboard and https://github.com/voxpupuli/pypuppetdb, which I contributed to and later gradually became a co-maintainer.

However I like the reasoning in the medium article that you shared, @amimas, and I agree that we should change our approach. :)

cc @bastelfreak - maybe we should change the approach for voxpupuli's projects too? At least for the Python ones?

[bastelfreak]

Hi,
my two cent here: At Vox Pupuli (we mostly have ruby-like projects) we try to support all versions of a language that are still maintained. For Ruby that's currently 2.7-3.2 and for python 3.8-3.11. I would love to reduce that but most users are unable to update that fast. They are often limited by stupid internal processes and operating systems that don't provide current ruby/python versions. When supporting old-but-not-dead versions like python 3.7 causes us a lot of trouble, because it would limit us in using latest pypi packages, we would drop it.

Dropping a major language version is always a major/breaking change. From a semver point of view it's debatable, but we learned that most users read only changelogs for major releases properly. If we drop support for one major language version in a minor release, people won't notice it, update, stuff breaks, they raise issues in our projects and I get sad because I need to spend time answering pointless issues.

tl;dr: I suggest to do major releases when dropping a major language version.

[amimas]

most users read only changelogs for major releases properly. If we drop support for one major language version in a minor release, people won't notice it, update, stuff breaks, they raise issues in our projects

But, they wouldn't be able to update to newer version if they don't have required language versions, right? So, things shouldn't break?

I could be wrong. I don't have experience with pypi package management. Would they be able to update if they don't have Python version >= 3.8? I've been consuming gitlabform as a docker container 🎉 .

Don't want to get into semvar debate, but I think if we're following semantic versioning, then that's all we need to follow. Would've been nice if there was a clear guideline on this topic from semvar/semantic-versioning scheme (or maybe I missed it). It shouldn't be based on whether or not people read changelogs or follow best practices (i.e. pinning down dependency versions) 😄

[bastelfreak]

I could be wrong. I don't have experience with pypi package management. Would they be able to update if they don't have Python version >= 3.8?

I am not a Python expert, but I know that Ruby ignored the version constraint for years so people had to read changelogs and could not trust the package manager.

At Vox Pupuli we follow "better safe than sorry". Doing a major release for something that could have been a minor one is less bad compared to a minor release that contains breaking changes.

[gdubicki]

I am not a Python expert, but I know that Ruby ignored the version constraint for years so people had to read changelogs and could not trust the package manager.

Python's pip does read the packages metadata that contain the information about supported Python versions correctly.

[gdubicki]

Let's remove 3.7 support and release a minor release of gitlabform with it.

But I would still support Python 3.8 and 3.9 as long as it does not require us to do extra maintenance as it is beneficial for users who are stuck with older versions of Python (f.e. on Centos 7 it's relatively easy to have Python 3.8, but harder to have newer). Running those tests in parallel does not cost us time.

Ok, @amimas?

[amimas]

Yeah, that makes sense @gdubicki . I agree with you totally. There's no urgency on dropping 3.8 or others. 3.7 is the only blocker right now for us to keep our dependencies up-to-date and possibly get newer dependencies for new features.