We are currently live on O3 using the original workspace implementation (Workspace v1). Recently, Workspace v2 was introduced on main, and it includes breaking changes and is not yet considered stable.
However, since Workspace v2 landed, several important bug fixes and improvements have been merged into main that are not inherently tied to Workspace v2. We would like to consume those fixes in production without migrating to Workspace v2 yet.
This puts us in a difficult position:
We cannot upgrade from main because it implicitly pulls in Workspace v2 and its breaking changes.
We still need patch-level releases for O3 to pick up safe fixes that were merged after Workspace v2 was introduced.
We want to avoid introducing breaking changes or unstable features into our live environment.
Questions
What is the recommended way to cut patch releases for O3 that:
stay on Workspace v1
include select bug fixes from main
do not introduce breaking changes from Workspace v2?
Is there an established workflow (e.g. release branches, cherry-picking, or backporting) that maintainers recommend for this scenario?
Longer-term, how should teams running production systems handle situations where breaking architectural changes land on main before they are stable?
Our goal is to stay secure and up-to-date with critical fixes while avoiding premature adoption of Workspace v2 until it is stable.
FWIW, we do not regard Workspaces V2 as “unstable”, which is part of why it’s integrated across the main branches at this point.
In general and where feasible we try to limit the number of cases where even “breaking” changes in the framework break things. Unfortunately, while Workspace V2 fulfills the same functions and the older Workspace system, it does so in ways that are not compatible with running the two of them side-by-side.
@kmakombe another option is to evaluate and compare the amount of work it would take you to upgrade your esms to the workspaces v2 vs having to cherry pick and maintain previous branches. There are some cases where simply upgrading is the cheaper and more sustainable option. Typical tradeoffs that an architect would consider before choosing a path to take.
Patch releases in O3 are possible. I actually had a similar discussion about it a few months ago. We have a tracking ticket here, that if we make a commit to a branch named patch/*, it should publish a version to npm. (Normaly, only commits to the main branch publishes a version to npm.) So far, this is only implemented in the esm-patiant-chart repo, but it should be straightforward to make similar changes to the ci.yml github action files in other repos.
That said, going down this path requires carefully cherry-picking commits you want to include in your patch, and it’s usually best if the commit you’re basing your patch off of is relatively recent. As the workspace v2 changes have been in for 2 months now, this might be a daunting task.
