On Fri, 2024-10-04 at 12:16 +0100, Stephen Finucane wrote:
Ok, I get your idea now.
Honestly, I do not think this plan works fine. As Takahshi mentioned, services are not removing the support aggressively, and it is hard to finish the service side work before the deadline. Even if we give them the same cycle deadline or the next one and make libs a little slow to drop the older version, the situation will be the same. We will be bumping the min version in libs, breaking the service gate. Py3.8 drop is the best example to see this situation where services have not dropped the support, and Oslo had to bump the min version as python 3.8 is EOL and cannot be supported in Oslo anymore. That is the main reason I think dropping this flag from libs/client will solve this problem.
It sounds like the real issue lies with the services, rather than the libraries: if the services were always updating their 'python_requires' to reflect the lower bound of our tested runtimes matrix then we wouldn't have an issue, right? Perhaps we could make this slightly easier by auto-proposing bumps of this at the start of a new cycle (where appropriate)?
because of the slurp lifecycle and new yearly cadance of python that would be teh start of every slurp relase exlucing release where for smoth upgrade we need to supprot the previous python. i.e. we shoudl already requrie 3.9 for 2025.1 for 2026.1 we could move to 3.10 however since we need to supprot upgrade form centos 9 stream (3.9) to centos 10 stream(3.12) we cant actully mkae 3.10 the min until 2026.2
That won't guarantee that they'll get merged (you can bring a horse to water...) but at least it sends a signal around expectations for service-type projects and give libraries cover as they do the same later?
Stephen