[all] Dangerous trend toward too many release-independent components
fungi at yuggoth.org
Tue Sep 7 23:21:44 UTC 2021
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
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:
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:
Does this help narrow the scope of concern to the point where we can
better reason about the problems or challenges you're facing?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 963 bytes
Desc: not available
More information about the openstack-discuss