Leveling up our Patch release process

[thedavidprice]

@peterp starting with this next release, I'm going to focus on opportunities to resolve bugs more quickly via patch releases. Here's how I understand the process that will work with the canary release automation:

1. Create a new branch from the previous release tag, e.g. git branch v0.27.2-patch v0.27.1
2. Open a PR against the patch branch, e.g. v0.27.2-patch
   • if the PR working branch was not created originally from v0.27.2-patch, it should be rebased against the branch
3. Merge the PR
   • note: this should not trigger canary release automation (to confirm)
4. Create a patch release using the updated patch branch, e.g. v0.27.2-patch released as v0.27.2
5. Create a new PR for the patch branch against main, e.g. v0.27.2-patch --> main
6. Merge the PR, which will trigger canary release automation
   • this should release a canary with tag v0.27.3-canary.x, correct?

TO DO

• finalize instructions
• confirm canary release only triggers on push to main
• Document in Contributing.md

[peterp]

I've had to do this now, but followed a slightly different process, just thought I would write it down so that it's documented

#2130

1. git checkout tags/v0.28.0 -b v0.28.1
2. Pick the merges that I want in v0.28.1: git cherry-pick d8649c98056d5aefccf972d11461d469c3821b2f

dsp edit: we need to add a "compare branch to previous version" step here to verify only patches are included

3. Bump the versions: ./tasks/update-package-versions 0.28.1

dsp edit: add commit here

4. Create a new tag: git tag -am v0.28.1 "v0.28.1" dsp edit: need to annotate!
5. Push that up to GitHub: git push --tags
6. Create a new PR and make sure that everything builds and passes

dsp edit: curious if you also ran into a gazillion merge conflicts from version updates in packag.json files

7. Publish the new npm packages
8. Create release in GitHub.
9. Merge main back into my branch (fix conflicts)

dsp edit: interesting, after resolving merge conflicts I then pulled back locally, which also included commits from main. I did not specifically update from main. Must have been included in the conflict resolution process.
dsp edit: this might also be a good step to update template/yarn.lock

9. Merge PR.

dsp edit: PR merge using "Squash & Merge" is likely to remove the Tag'ed commit. Recommended to use regular merge and keep individual commits.

[thedavidprice]

@peterp it looks like #2082 and #2085 snuck into v0.28.1 I originally merged them so we could leave in canary for a cycle of testing. Guessing these snuck in. We should add a "compare" step to the processes above before publishing a patch.

v0.28.0...v0.28.1

Edit: confirming false alarm. Was likely comparing tag to branch, which I swore I double checked

[thedavidprice]

So, I’m trying to figure out how to update the new template/yarn.lock. Here’s my dilemma, it needs to be done based on the packages that will be released.

• publish v0.28.3
• using the published v0.28.3, run yarn install to update template/yarn.lock

But I can’t do this because it’s all in the same repo and gets published simultaneously.

The best I could do is update yarn.lock after the packages are published, so it would always be a version behind.
When a user runs CRWA and yarn install for the first time, yarn.lock will be updated. But they won’t know it because likely they haven’t git init yet. Maybe this is all fine. But it doesn’t feel silky smooth in my 🧠 yet.

We will always have a "baseline" to work against. But not having yarn.lock is also a baseline. But now we need to make sure we're manually managing the baseline and doing it in a regular, transparent manner.

[jtoar]

I'm not sure if #4402 totally closed this yet so reopening for now.

[thedavidprice]

Final piece here will be automating the rc publishing

[jtoar]

Final piece here will be automating the rc publishing

I think we can close this one now that we've got that down.