<div dir="auto"><div dir="auto" style="min-width:150px" class="elided-text"><blockquote style="min-width:150px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>deprecateion are allowed in non slurps we just cant remove supprot for a depreaction<br>that has not been release in slurp.</blockquote></div><div dir="auto"><br></div><div dir="auto">Yes, thanks for correcting me, that's eventually what I meant, though picked misguiding words to the express that.</div><div dir="auto"><br></div><div dir="auto" style="min-width:150px" class="elided-text"><blockquote style="min-width:150px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><div dir="auto"><br></div><div dir="auto" style="min-width:150px" class="elided-text"><blockquote style="min-width:150px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">ingoring that for a moment the deprecation poilcy</blockquote></div><div dir="auto" style="min-width:150px" class="elided-text"><blockquote style="min-width:150px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">only applies to aplciation feature we have never applied it to runtimes or minium python<br>version.<br></blockquote></div><div dir="auto"><br></div><div dir="auto" style="min-width:150px" class="elided-text"><blockquote style="min-width:150px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">> 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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I know I m a bit exaggerating here, but it's kinda close.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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...</div><div dir="auto"><br></div><div dir="auto">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. </div></div>