On 2021-12-01 12:46:08 -0700 (-0700), Alex Schultz wrote: [...]
For this reply, "LTS Distro" means support/updates > 13 months This means regular Ubuntu and Fedora releases don't qualify. Ubuntu LTS, CentOS Stream * and Debian LTS would qualify. Can we all agree on this definition?
https://ubuntu.com/about/release-cycle https://www.centos.org/cl-vs-cs/#end-of-life https://wiki.debian.org/LTS [...]
Technically, Debian on its own would meet this definition, as releases come every ~2.5 years and are generally supported for ~6 months after the next release, making it roughly 3 years of normal support. "LTS" in Debian is something which extends beyond the normal security support for the distribution, but is irrelevant here given the already long support timeframe for Debian releases.
Jeremy said in a subsequent message that the interpreter comes from an LTS distro which IMHO means the EOL is the distro's EOL not Python's. Now this brings up issues if we can't get 3.6 fixes for specific versions of our dependencies that come in via pypi, but do we have data how often this is actually a problem?
You can get some idea by counting the number of times "python_version" appears in global-requirements.txt or upper-constraints.txt in openstack/requirements by the end of a release cycle.
Isn't that already a problem for stable branches?
Not really, since we freeze openstack/requirements when branching, in a crude attempt to mimic testing with versions contemporary with what distros are probably packaging alongside that OpenStack release.
Or are we worrying about something that doesn't happen? We need to all agree on where EOL dates come from for dependencies and expectations around them.
It's definitely a thing which happens. We're running Python 3.6 jobs on OpenStack project master branches now while pinning to older versions of more than a dozen dependencies, and when mainline 3.6 EOL comes that will almost certainly rise sharply as our dependencies start to aggressively drop support for it. Having this happen during a cycle definitely leads to a wider disparity in versions of dependencies used for various jobs, compared to having it happen after we freeze requirements for the release.
LTS Distros are being referenced in this thread but people keep going back to EOL dates that are not aligned with these distros. For the full OpenStack project ecosystem, testing is occurring on Ubuntu, CentOS, and a bit of Debian. IMHO when a release (e.g. Yoga) is released, we should use what is available at the start of cycle and using the EOL dates of the tested distros in determining decisions around version support. If we use this for Yoga, realistically CentOS Stream 8 and Ubuntu 20.04 could be used which would leave us with 3.6/3.8. It seems Debian was the only one with 3.7 (https://wiki.debian.org/Python). Since CentOS Stream 9 was released during the Yoga cycle, we couldn't pick it up as a version until Z but we could then make the 3.8 cutoff then. If Ubuntu releases a new version (the website says they might) during Yoga with 3.9 then we could talk about raising it further in Z. This would allow for lower bounds to be pushed, but requires that one of our qualifying LTS distros in check/gate were already available at the start of a cycle.
Actually, Debian's last stable release (11 a.k.a. bullseye) was available approximately 2 months before we started on OpenStack Yoga and uses Python 3.9 as its default python3, so testing 3.6 and 3.9 would be the preferred lower and upper bounds there.
What I would like is that people stop pointing to Python's EOL date which is newer but does not actually align with the assumption of an LTS distro. It would only make sense to use that date if we were basing our testing on non-LTS distros which may be able to follow their EOL dates more closely. [...]
The underlying reason it keeps coming up is that, during development, we don't attempt to match the versions of dependencies we test with to the versions those distributions are packaging alongside the Python 3 interpreter. As a result, when our dependencies begin dropping upstream support for Python releases is what impacts us, at least under our current testing model. -- Jeremy Stanley