On 9/7/21 3:39 PM, Jeremy Stanley wrote:
On 2021-09-07 11:09:45 +0200 (+0200), Thomas Goirand wrote: [...]
since we have pinned global requirements, will these new updates be included in the tests of older OpenStack releases? Is this really the case right now? [...]
They generally shouldn't, and most of the time can't realistically, have their entries altered in stable branches of the upper-constraints.txt file we use to pin dependency versions. To be able to do so would prevent them from using new features of their own dependencies in master branch development, since those would end up also needing updates in the pinned list of transitive stable branch constraints, which is exactly what we want to avoid.
The workaround is to create a stable branch of the repository from the last version which was tagged during the cycle for the release which needs a fix to that independent deliverable backported. Those cases are rare, and basically what you would include as a stable distro package update for that coordinated release series anyway.
Hi, Thanks for your insights. Basically, what you're writing above confirm what I thought: the release-independent components are in fact not really release-independent, and are bound to a specific release of OpenStack. Most of the time, they aren't updated in the stable release CI. Therefore, it would probably be wise to try to minimize the amount of release-independent components to reflect this reality. In fact, I was particularly confuse to realize that something like taskflow was declared release-independent since Wallaby. Now, if I'm told that it is loosely coupled with OpenStack, knowing that it's a key component, I'm not sure what I should do. Should I get taskflow updated to 4.6.2 in Wallaby, so I get bugfixes? Or is it safer to just upgrade it for Xena? I took Taskflow as an example (you can reply to me about Taskflow in particular, but that's not the point I'm trying to make). But it could have been something else (deptcollector? oslo.i18n?). What I'm trying to say is that as a downstream consumer, it's from hard to impossible to know what to do for the past OpenStack releases regarding these release-independent components: should I update them or not? It is unrealistic to hope that one can track what component has been updated to a newer version in the stable release CI. Therefore, if possible, I would prefer clearer, easier to track, release-bound components with point release updates (though I understand that it may not be possible if that's too much work and OpenStack is getting understaffed...). Cheers, Thomas Goirand (zigo)