On 2021-09-08 00:46:30 +0200 (+0200), Thomas Goirand wrote: [...]
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.
Specific examples are great actually, because it at least lets us try to formulate a specific answer and then reason about whether a similar answer can be generally applied to other related scenarios. So let's take taskflow in Wallaby and Xena: The closest thing we have to a recommendation for versions of "outside" dependencies (which is essentially what we treat release-independent deliverables as) is the upper-constraints.txt file on each branch of the openstack/requirements repository. In the case of taskflow, at the moment the stable/wallaby branch upper constraint for taskflow is 4.6.0, which is the version we indicate all OpenStack projects should test their stable/wallaby changes against. That entry was last updated by https://review.opendev.org/773620 which merged to the master branch of openstack/requirements in February, well before the coordinated Wallaby release. Even though the master (upcoming Xena coordinated release) upper-constraints.txt file lists taskflow===4.6.2, we don't test stable branch changes of OpenStack projects with that, only what will eventually become stable/xena once the Xena cycle concludes.
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...).
It seems like what you're asking for is this: https://opendev.org/openstack/requirements/src/branch/stable/wallaby/upper-c... Or rather, that's the closest thing we have to what I think you're requesting. If you follow the commit history of that file, you'll see recent updates for it on the stable/wallaby branch do consist almost entirely of stable point releases of cycle-oriented projects: https://opendev.org/openstack/requirements/commits/branch/stable/wallaby/upp... Does this help narrow the scope of concern to the point where we can better reason about the problems or challenges you're facing? -- Jeremy Stanley