Changing our release process and workflow

[jonrohan]

Recently we've run into friction with our current release process, and I wanted to start a discussion with ideas on how we can improve it.

Problems with our current system

• Since we treat main as the next release, we find ourselves having to block pull requests from landing so that a release is easy to ship.
• After merging a release PR main is treated as the current release, if in the time we go to ship that release we discover an issue, it can be difficult to make a patch release for that issue especially if there's already work merged in for the next release.

Below I want to list some ideas and we can discuss them separately.

[jonrohan]

Tag based release workflow

What if we leaned more heavily into the GitHub releases. Instead of working off of a changeset pull request that needs to be merged in, we could tag the codebase at specific points create releases.

How this might work

1. On monday release conductor tags main with a release checking the "pre-release" box.
   
2. Pre-release is published and we have workflows publish to npm for us.
3. In dotcom we install the pre-release (could be automated with workflow to install from a tag like next)
4. If changes are needed, we publish a second pre-release.
5. Once release integration feels good, we can publish the full release and change the settings to set this as the latest release.

Some things that might need re-working

• Docs talking about changesets. We used this in the past to format the CHANGELOG file for us in a consistent way, but the github release product will fill this in for us now, we'd just need a hook afterwards to update the changelog.
• Integration actions we have in dotcom that ask for a release pr url will need to be updated. They could be updated to point at a release page.

[francinelucca]

if we could get this flow to work I think that'd be awesome!

Once release integration feels good, we can publish the full release and change the settings to set this as the latest release.

Wondering how this process goes? like would versioning still be merging in the release tracking PR? and would that happen before or after publishing the latest release?

[siddharthkp]

I like it!

Couple of doubts:

On monday release conductor tags main with a release checking the "pre-release" box.

As we already publish release-candidates from main using the Release tracking PR, do we freeze the release tracking PR from accepting more updates from main?

If changes are needed, we publish a second pre-release.

Would this pre-release have other changes that have been merge in main since then or just pre-release 1 + fix?

[jonrohan]

Wondering how this process goes? like would versioning still be merging in the release tracking PR? and would that happen before or after publishing the latest release?

I think we wouldn't need to have the release tracking PRs anymore. We would create a tag via the releases ui off of the latest release candidate.

[jonrohan]

As we already publish release-candidates from main using the Release tracking PR, do we freeze the release tracking PR from accepting more updates from main?

I'm thinking we would just tag main periodically and work off the tag. Wouldn't require release tracking PRs

Would this pre-release have other changes that have been merge in main since then or just pre-release 1 + fix?

Good question. I think we would checkout the previous pre-release tag, apply the fix by merging the sha in, and then pushing a new pre-release tag.

[lesliecdubs]

Let's revisit this idea if the need comes up. In the meantime, we'll experiment with @joshblack's idea to tag release branches.