Open Stack

On Wed, Oct 11, 2023, at 10:19 AM, Dmitriy Rabotyagov wrote:
> To be fair, all these arguments were also raised during the 2023.2 
> development cycle. With additional one - we will be not able to drop 
> support during non-SLURP release without breaking 
> upgrades/compatibility between SLURPs. A decision was taken to keep 
> py3.8 back then with acknowledgement of that fact.
>
> Now, when 2023.2 has been released with py3.8 support, from my 
> perspective there is really no way it can be removed until 2024.1 
> without breaking someone's upgrades.

I'm not sure this is the case? 2023.1 and 2023.2 (the two releases you might upgrade from to 2024.1) both support python 3.9 and python3.10 in addition to python3.8. 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.

>
> Despite I agree with your arguments, TC has quite explicitly stated 
> that deprecations should not take place in non-SLURP releases according 
> to [1] and I believe that reasons and background in this resolution are 
> still valid and should be respected, despite how inconvenient it might 
> be sometimes. As also platform consumers rely on that and plan their 
> maintenance and further work based on promises that are being made by 
> community.
>
> In case a key library drops support for py3.8 then I believe we will 
> need to leverage upper-constraints to set the version back for the 
> library to the one which supports py3.8. Either for all python 
> versions, or solely for py3.8, like we already did for py3.6 and py3.8 
> back in Xena/Yoga.

I think the big struggle with dropping python3.8 previously was the order of operates was backwards. Services need to drop python versions first, then libraries. This will require coordination across openstack which is what we didn't have the last time we attempted this.

>
> [1] 
> https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html#details