You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For each of the last few major releases, we've had to bake a custom image after some small-but-fatal error popped up when deploying. As @sciurus said, it's not warm-fuzzies to be running a hand-built image (more accurately yarn build --push on a developer's system) in production. We've had to do this because deployments have lagged releases, so we're updating deployments to versions that aren't the latest release.
Let's add a way to go back to each major release and make minor or patch releases from it.
I think the tricky bits are:
yarn release checks that the current commit is the latest on the upstream main branch, so that would have to change
changelog / GH releases: how do we represent that e.g., 36.0.1 was a different line of development from 37.0.0?
policy: what can land on a release branch? does that need to be a backport? does it need to be forward-ported? Do we only allow patch releases?
The text was updated successfully, but these errors were encountered:
For each of the last few major releases, we've had to bake a custom image after some small-but-fatal error popped up when deploying. As @sciurus said, it's not warm-fuzzies to be running a hand-built image (more accurately
yarn build --push
on a developer's system) in production. We've had to do this because deployments have lagged releases, so we're updating deployments to versions that aren't the latest release.Let's add a way to go back to each major release and make minor or patch releases from it.
I think the tricky bits are:
yarn release
checks that the current commit is the latest on the upstreammain
branch, so that would have to changeThe text was updated successfully, but these errors were encountered: