Yes, thanks for correcting me, that's eventually what I meant, though picked misguiding words to the express that.

I'm not sure it's specified in resolution? To be frank, dropping an application feature is way less deal breaker then dropping python version, imo. I would compare it more with bumping min libvirt version then (which is not supported by some platform).

> Your upgrade path would be to first update your runtime on 2023.x from python3.8 to 3.9/3.10 then upgrade to 2024.1.

Sorry, I can't agree here with you Clark. With that we can also drop platforms as well and tell users to upgrade OS in between of SLURP releases.

I know I m a bit exaggerating here, but it's kinda close.

Simple example of operations life - we have to schedule all planned maintenances in a 6month before doing them. And if our plan was, for example, involving openstack upgrade to 2024.1, but then, from the blue sky, despite decision that was just taken by TC, I see that I need to do some OS upgrades before that, it would break plans quite dramatically. This would put into position, that by the time of the next possible planned maintenance OpenStack version I am using (and was supposed to be upgraded 6 month ago) is already unmaintained.

I am not saying that py3.8 drop is affecting us specifically in this way (dropping a platform would though), but just giving a perspective that such decisions might result in quite some overhead for end users, especially when they in a way contradict with existing TC decisions. I'm not even saying that such thing can easily deduct available time for upstream contributions...

But also there should be a trust in TC decisions from end users, so that they know these can't change overnight and can be relied on. As otherwise it would be pretty much hard to convince enyone, that you can rely on OpenStack as a project.