docs: fix old information in RELEASING.md

Update for how we use tags instead of make bump.

RELEASING.md

@@ -48,7 +48,7 @@ git merge --ff-only release_${version}
 git push origin release
 ```
 
-10. Run [`make bump`](#make-bump-usage) to tag the release and start release builds:
+10. Tag the release and start release builds:
 
 ```shell
 git tag -a v${version} -m 'chore(release): ${version}'
@@ -71,7 +71,7 @@ git merge --no-ff release
 ## Releasing Robot Software Stack Hotfixes
 
 1. Ensure you have a system release created in GitHub (buildroot for OT2, oe-core for OT3) with all the changes you want to see, if any. If there aren't any, you don't have to create a new release; by default, the last tag is used for release builds.
-2. Checkout `release` and make a release branch, without any new changes. The branch name should match `hotfix_*` to make it clear this is a hotfix, and make `make bump` usage simpler.
+2. Checkout `release` and make a release branch, without any new changes. The branch name should match `hotfix_*` to make it clear this is a hotfix.
 
 ```shell
 git checkout release
@@ -82,11 +82,18 @@ git push --set-upstream origin hotfix_${version}
 
 3. Target the hotfix PRs on this branch.
 4. Wordsmith the release notes in `app-shell/build/release-notes.md` and `api/release-notes.md` in a PR that uses the `chore` commit type.
-5. Once the fixes and release notes have been merged into the hotfix branch, bump to an alpha version to begin qa using [`make bump`](#make-bump-usage).
+5. Once the fixes and release notes have been merged into the hotfix branch, bump to an alpha version to begin qa - for instance, if this is a hotfix following 6.3.0, the `${version}` would be `6.3.1-alpha.0`:
+
+```shell
+git tag -a v${version} -m 'chore(release): ${version}'
+git push origin v${version}
+```
+
 6. Inspect the created tag and then push it:
 
 ```shell
-git push ${tag}
+git show v${version}
+git push v${version}
 ```
 
 7. Once QA is a pass, do a NORMAL MERGE into `release`. Do NOT squash or rebase. This should be done from your local command line (and will succeed as long as the release PR is reviewed and status checks have passed):
@@ -99,7 +106,12 @@ git merge --ff-only release_${version}
 git push origin release
 ```
 
-8. Tag the release using [`make bump`](#make-bump-usage)
+8. Tag the release with its full target version:
+
+```shell
+git tag -a v${version} -m 'chore(release): ${version}'
+git push origin v${version}
+```
 
 Pushing the tag will create release builds and a github release page with the in-depth changelogs.
 
@@ -116,69 +128,18 @@ git merge --no-ff release
 
 ### tag usage
 
-If you know the version (at this stage, it should be a new minor or patch version with an alpha tag) you can specify it with `version` and `project`, where `project` is one of our multi-application projects: `docs`, `robot-stack`, `labware-library`, `protocol-designer`, `ot3`:
-
+We specify the version of a release artifact through a specifically-formatted git tag. We consider our monorepo to support several projects: robot stack, ot3, protocol-designer, etc. Tags look like this:
 ```shell
-make bump project=${project} version=${version}
+${projectPrefix}${projectVersion}
 ```
 
-i.e.
+`${projectPrefix}` is the project name for everything but robot stack, where it is `v`.
 
-If not, you can follow the prompts:
-
-```shell
-make bump
-Enter the project (labware-library,docs,robot-stack,ot3,protocol-designer):
-The current version of ${project} is ${current-version}
-The next prerelease version of ${project} would be ${version}
-The next release version of ${project} would be ${version}
-Enter version exactly or bump type (prerelease,alpha,beta,candidate,release)
-version:
-```
+For instance, the tag for 6.2.1-alpha.3 of the robot stack is `v6.2.1-alpha.3`.
+The tag for 4.0.0 of protocol designer is `[email protected]`.
+The tag for 0.1.2-beta.1 of ot3 is `[email protected]`.
 
-`make bump` runs `lerna version` (with git tag and push disabled) to bump all required files. You can pass options to lerna with the `version` environment variable. See the [lerna version docs][lerna-version] for available options. The most important options are:
-
-- First positional argument: bump type _or_ explicit version
- - Default: `prerelease`
- - Valid bumps: `major`, `minor`, `patch`, `premajor`, `preminor`, `prepatch`, `prerelease`. Alpha versions should be created with `premajor`, `preminor`, `prepatch`, or `prerelease`. Releases should be `major`, `minor`, or `patch`.
- - See [semver.inc][semver-inc] for keyword meanings
-- `--preid` - Used to specify the pre-release identifier
- - Default: `alpha`
- - Valid: `alpha`, `beta`
-- `--allow-branch` - Specifically allow a branch to be bumped
- - By default, Lerna will only accept a bump on a branch named `release_*` or `hotfix_*`
-
-```shell
-# by default, bump to next alpha prerelease:
-# e.g. 3.0.0 -> 3.0.1-alpha.0
-# e.g. 3.0.1-alpha.0 -> 3.0.1-alpha.1
-make bump
-
-# equivalent to above
-make bump version="prerelease"
-
-# bump to a beta version, the standard practice for a new release
-make bump version="prerelease --preid=beta"
-
-# prerelease minor version bump (e.g. 3.0.0 -> 3.1.0-alpha.0)
-make bump version="preminor"
-
-# minor version bump (e.g. 3.0.0-alpha.0 -> 3.1.0)
-make bump version="minor"
-
-# bump to an explicit version
-make bump version="42.0.0"
-
-# bump a patch version, e.g. for a hotfix
-make bump version="patch --allow-branch hotfix_*"
-```
-
-We use [lerna][], a monorepo management tool, to work with our various projects. You can use lerna to do things like see which projects have changed since the last release, or run a command in every project directory. To run a one-off lerna command, use:
-
-```shell
-# use yarn run to run devDependency CLI tools like lerna
-yarn run lerna [opts]
-```
+Versions follow [semver.inc][semver-inc]. QA is done on alpha builds, and only alpha tags should be pushed until you're ready to release the project.
 
 ## Releasing Web Projects