Opentrons: RFC: Pre-release version-bump process

[mcous]

overview

This is an RFC ticket to spec out a basic version-bump process to get us started with releasing. Even while we're prerelease on v3, we need to track our releases in order to support internal / beta users.

proposal

I think we should start with a fairly manual process. After using it for a little, we can refine before we go ahead and automate / script what we like.

I've got two options here and I'm wondering which one y'all prefer. Vote by adding a reaction to this PR:

Option A: 🎉
Option B: 😆

1. Option A only: Create a release branch: release_${version}
2. Bump pre-release version in <root>/package.json
3. Run python scripts/bump_version.py --sync
   
   
   
   • Syncs the bumped version with all the projects
   
   
   • Not using --major, --minor, and --bugfix options just yet
   
   
   • Could also update script with a --pre option to do (1) automatically
   
   
4. Run make install test lint
   
   
   
   • Updates api's __version__.py file
   
   
   • Also, you know, important for safety
   
   

option A

1. Commit the bump to release branch with message: release: ${version}
2. Open a release pull request into edge
3. Get 👍s
4. Merge PR
5. Fetch/pull/checkout latest edge on your machine
6. git tag -a v${version} -m 'release: ${version}
7. git push --tags

option B

1. Commit the bump directly to edge with message: release: ${version}
2. git tag -a v${version} -m 'release: ${version}
3. git push --follow-tags

notes

yarn has a built in command yarn version that launches a version bump wizard to update package.json and tag the commit. In combination with the preversion and postversion package.json scripts calling various git commands and bump_version.py, we could probably simplify both option A or B

[btmorr]

Soft preference for B because it avoids the PR back into edge, but either works

[btmorr]

Also, it seems like edge is the right place for beta and RC releases, but once we've got a release candidate that we're happy with and actually calling it a stable release, we should merge it over top of master

[mcous]

Soft preference for B because it avoids the PR back into edge, but either works

Not that it should be used as justification for a process, but option (B) is what I'm most used to and how the default yarn version command works.

once we've got a release candidate..., we should merge it over top of master

Absolutely. I wanna see how we do with pre-releases so we can end up with something sane and straightforward for actual releases in master

[IanLondon]

B seems more straightforward to me.

Don't wanna derail here, but elsewhere we should also discuss: How do we decide when it's time to do a new release, and how do we communicate it (at least internally)? We've been having an ongoing convo around that, but have we written down our release process anywhere?

[mcous]

How do we decide when it's time to do a new release, and how do we communicate it (at least internally)?

Super important point that I'd love to be a part of this discussion. We haven't written anything down, but also nothing's really decided. @umbhau @btmorr or @Kadee80 do y'all have any thoughts? Could we do it in sprint planning? e.g. have a release ticket that tracks several other tickets, and when they're closed out we issue the release?

[btmorr]

@mcous This seems like a sensible use of milestones

[mcous]

Closing this RFC as we have settled into a process. Further process improvements will happen in new tickets