Remove dot from alpha and beta version names in docs (#450)

* Remove dot from alpha and beta version names in docs

* Remove dot in one more place

docs/release-process.md

@@ -5,15 +5,15 @@ Once the release is on the CDN the auto-update process will start downloading th
 
 ## Creating a Release
 
-These instructions are for creating version 0.1.0-alpha.5, but the steps are the same for releases with no pre-release tag.
+These instructions are for creating version 0.1.0-alpha5, but the steps are the same for releases with no pre-release tag.
 
-1. Create a PR which updates the `version` field in `package.json` to `'0.1.0-alpha.5'`.
+1. Create a PR which updates the `version` field in `package.json` to `'0.1.0-alpha5'`.
    - Remember to run `npm install` so the version in `package-lock.json` gets updated too.
 2. Merge this PR.
 3. Make a note of the commit hash of the PR which was just merged into `trunk`, e.g. `a1c70f3a3be5d28922a48f7f298f6152d6001516`
-4. Tag this commit with `v0.1.0-alpha.5`:
+4. Tag this commit with `v0.1.0-alpha5`:
    1. On your local machine get the latest code: `git checkout trunk && git pull`
-   2. Create the tag: `git tag v0.1.0-alpha.5 a1c70f3a3be5d28922a48f7f298f6152d6001516`
-   3. Push the tag to the GitHub repo: `git push origin v0.1.0-alpha.5`
+   2. Create the tag: `git tag v0.1.0-alpha5 a1c70f3a3be5d28922a48f7f298f6152d6001516`
+   3. Push the tag to the GitHub repo: `git push origin v0.1.0-alpha5`
 
 Pushing the tag will automatically start the build and release process, and is complete when the build finishes cleanly.

docs/versioning-and-updates.md

@@ -4,7 +4,7 @@
 
 Studio uses [semver](https://semver.org/)-style version numbers.
 
-`0.1.0` < `0.2.0` < `0.3.0-beta.1` < `0.3.0`
+`0.1.0` < `0.2.0` < `0.3.0-beta1` < `0.3.0`
 
 ## “Dev Builds” and “Release Builds”
 
@@ -14,7 +14,7 @@ changeset it was built from.
 
 A **release build** is version of the app built from a specific changeset that
 was chosen by a member of the team by applying a tag to the changeset. It has
-version numbers that look like `1.2.3` and `0.1.0-beta.3`. Notice a beta is
+version numbers that look like `1.2.3` and `0.1.0-beta3`. Notice a beta is
 still considered a release build. They’re built using the same mechanism and are
 out in the wild, generating entries in Sentry etc. From the team’s point of view
 there’s no real difference between a beta and a non-beta build.
@@ -23,8 +23,8 @@ there’s no real difference between a beta and a non-beta build.
 
 Studio’s version is defined in `package.json`. When it’s time to bump to the next
 version the new version number should be committed in `package.json`
-(e.g. `"version": "1.0.1-beta.1"`). To run the release build in CI the changeset
-should be tagged (e.g. `v1.0.1-beta.1`). CI will pick this up automatically.
+(e.g. `"version": "1.0.1-beta1"`). To run the release build in CI the changeset
+should be tagged (e.g. `v1.0.1-beta1`). CI will pick this up automatically.
 
 `package.json` is the authoritative source of the version info, not the tag. But
 duplicating the version number in the tag is still useful for comparing

scripts/generate-releases-manifest.mjs

@@ -32,8 +32,8 @@
 //     },
 //     ... etc.
 //   },
-//   "1.0.1-beta.1": { ... },
-//   "1.2.1-rc.3": { ... },
+//   "1.0.1-beta1": { ... },
+//   "1.2.1-rc3": { ... },
 // }
 //
 // The "dev" entry will be replaced with the latest build from trunk.