Having recently updated our forge component list, we have run into issues afterward.

For the purposes of this explanation, I refer to two different concepts with specific terminology to differentiate them:
1) the "Forge component version" refers to the official version number of a forge component as seen on the forge:

2) The "Published version" refers to the code version of a forge component that is currently published:

A number of the forge components we updated were dependent on OutsystemsUI getting updated. So, after updating OutsystemsUI we were able to update these forge components.

However we soon experienced problems with OutsystemsUI's behaviour. So we republished the previous "Published version" , and that fixed our issue.

So. On to the problem.

This however left us with a dilemma: OutsystemsUI was now on the newest "Forge component version" meaning it wouldn't show up on the list of forge components needing to be updated in service studio, and also cannot be updated directly using the "forge" tab in service studio, as it believes it's on the newest version.

But the "Published version" is an older one.

This also meant that the dependent components which had been updated were on their newest version (both "Published version" and "Forge component version") - a version that is likely not compatible with the original OutsystemsUI "Published version" that we had rolled back to.

So we manually downloaded the old "Forge component version" of OutsystemsUI that we wanted from the forge and installed it the old fashioned way, which updated the forge component version to show the correct version number: (the "Forge component version" and "Published version" now match and is back to a version we that was running happily).

Grand. That fixes OutsystemsUI.

But what about the other components that I cannot see what their previously installed "forge component version" was, and that likely won't play along with the new OutsystemsUI?

I can roll them back by just publishing the previous "Published version"  on service center, which will bring them back to a published version that will play along with the old OutsystemsUI that we have rolled back to, but we will have to do the manual route to get their "Forge component versions"  back to reflect what is published. Until we do so we won't be able to do automatic upgrades in Service studio like this:

And we have no way of seeing what their previous "Forge component versions" were, so what do we roll them back to?

We can fix it in a long and convoluted process of trial and error and download and test if everything works, but surely there must be some form of best practice for rolling back a forge component that when your applications don't like it, and there are there forge components already installed dependent on the new one you wish to roll back.

Does anybody have an answer on how to do this in a clean way, or a best-practice-abiding way?