Philosophical (?) question on support for defunct Python versions..

[RookieRick]

So in the course of releasing 1.12 this evening I ran into a little snag.. PyYAML (which we were getting as a transient requirement of another library) after version 5.2 dropped support for Python 3.4 (which reached EOL in March 2019). This in turn caused our Travis build to fail because our Travis config still includes Python 3.4. My hamfisted workaround was to pin PyYAML <= 5.2 for now..

So the philosophical question is: Would you as a Python developer consider it a "breaking change" if instead of pinning PyYAML to maintain support for 3.4, I had simply removed Travis build vs. 3.4?

My gut (and heart) say we shouldn't need to do a major version bump every time a 5+ year-old version of Python reaches EOL, so pinning PyYAML feels kludgey, and I would personally lean toward just no longer including 3.4 as "formally supported" in Flask-Rebar (since we don't control when Python versions reach EOL), but as I'm still relatively new to managing a significant OSS project, I wanted to solicit some opinions. :) Seems like other libraries/apps (like PyYAML for example lol) take the approach of dropping old Python versions in minor version releases.

@barakalon @airstandley @sytten and/or anybody else have thoughts/experience from other projects on this?

P.S. @barakalon I haven't forgotten your suggestion to start doing beta/release candidates, nor does it escape me that this would have been a prime example of a great use case for that. I swear, I'm going to work that into the process.... 😂

[RookieRick]

I should add that I have fewer qualms with tying the dumping of major versions of Python (i.e., our hopefully-soon-to-be release 2.0 that will only support Py3) to a major version bump

[Sytten]

As long as we don't change the API, a major is not necessary to dump support for a python version. See Django for example, they stopped supporting Python 3.4 at version 2.1. We should actually start to prepare to drop 3.5 (for which I am very excited because it will allow us to use async stuff).

[RookieRick]

Nice - I like what they did with their explicit table there too.

[barakalon]

Philosophical (?) response:

Let's not forget that we're using semantic versioning. Here's a description from https://semver.org/:

In the world of software management there exists a dreaded place called “dependency hell.” The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.

In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.

As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. These rules are based on but not necessarily limited to pre-existing widespread common practices in use in both closed and open-source software. For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

I call this system “Semantic Versioning.” Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.

I believe the philosophical question here is whether or not the version of our package's dependencies count as part of our public API.

And there seems to be disagreement about that in the OSS community.

I think it's also worth noting that semantic versioning is not perfect. It improves dependency management, but it doesn't completely remove "dependency hell". There is still room for interpretation, and we have to use discretion to pick whether or not we want to lean "strict" or "promiscuous".

In this case, I'll borrow from the Zen of Python:

Special cases aren't special enough to break the rules. Although practicality beats purity.

Let's be practical here. What will be the actual impact of removing support for python 3.4 without bumping our major version? How many consumers of flask-rebar are using python 3.4? And if there are any, how painful will it be for them to blindly upgrade to the next minor version of flask-rebar, see that pyyaml has an issue, and pin their version of pyyaml?

[Sytten]

Considering that 3.4 is EOL, I think it's fair to remove support without bumping the major. I would not say the same for 3.5 for example. People should read the changelog before upgrading a minor IMO.

[RookieRick]

Let's be practical here. What will be the actual impact of removing support for python 3.4 without bumping our major version? How many consumers of flask-rebar are using python 3.4? And if there are any, how painful will it be for them to blindly upgrade to the next minor version of flask-rebar, see that pyyaml has an issue, and pin their version of pyyaml?

This is the big question that was in the back of my mind, with my presumed (and exaggerated) answers being "nobody is still using python 3.4" and "let them eat cake" :)

[barakalon]

It's also worth noting that pinning the pyyaml version was only done for the dev extras_require, which is only included if the the dependency specifies [dev] (like this).

So we've actually already gone ahead and removed python 3.4 support (in some dependency configurations) without bumping our major version 😂