formatting changes

CONTRIBUTING.md

@@ -399,11 +399,9 @@ If you create the key as `~/.ssh/robot_key` and `~/.ssh/robot_key.pub` then `mak
 
 Our release process is still a work-in-progress. The app and API projects are currently versioned together to ensure interoperability.
 
-
 1. Ensure you have a buildroot release created in GitHub with all the changes you want in this release, if any. If there are no buildroot changes, you don't have to create a new release; the last tag in buildroot is used for release builds.
 2. Checkout `edge` and make a release branch, without any new changes. The branch name should match `release_*` to make `make bump` usage easier and make it clear this is a release.
 
-
 ```shell
 git checkout edge
 git pull
@@ -432,26 +430,28 @@ git push origin v${version}
 12. Run QA on this release. If issues are found, create PRs targeted on the release branch. To create new alpha releases, repeat steps 4-11.
 13. Once QA is a pass, bump to the target release version (review [the section below](#make-bump-usage) again)
 14. Fix up the autogenerated changelogs to remove the references to alpha versions and make sure the release version has all changes since the latest release
- - Make sure the comparison link is to the latest release verison (e.g.: `compare/v3.11.4...v3.12.0)` instead of `compare/v3.12.0-alpha.1...v3.12.0)`)
- - Delete the sub-sections that relate only to alpha releases, so that the changelog is against the latest actual release
+
+- Make sure the comparison link is to the latest release verison (e.g.: `compare/v3.11.4...v3.12.0)` instead of `compare/v3.12.0-alpha.1...v3.12.0)`)
+- Delete the sub-sections that relate only to alpha releases, so that the changelog is against the latest actual release
+
 15. Do a NORMAL MERGE into `master`. 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):
 
 ```shell
-# note: make sure you have pulled the latest changes for branch 
+# note: make sure you have pulled the latest changes for branch
 # release_${version} locally before merging into master
 git checkout master
 git merge --ff-only release_${version}
 git push origin master
 ```
 
-15. Tag the release: 
+15. Tag the release:
 
 ```shell
 git tag -a v${version} -m 'chore(release): ${version}'
 git push origin v${version}
 ```
 
-16. Open a PR of `master` into `edge`. Give the PR a name like `chore(release): Merge changes from ${version} into edge`. Once it passes, on the command line merge it into `edge`: 
+16. Open a PR of `master` into `edge`. Give the PR a name like `chore(release): Merge changes from ${version} into edge`. Once it passes, on the command line merge it into `edge`:
 
 ```shell
 git checkout edge
@@ -466,7 +466,6 @@ git merge --no-ff master
 1. Ensure you have a buildroot release created in GitHub with all the changes you want to see, if any. If there aren't any, you don't have to create a new buildroot release; by default, the last tag is used for release builds.
 2. Checkout `master` 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.
 
-
 ```shell
 git checkout master
 git pull
@@ -495,26 +494,28 @@ git push origin v${version}
 12. Run QA on this release. If issues are found, create PRs targeted on the release branch. To create new alpha releases, repeat steps 4-11.
 13. Once QA is a pass, bump to your target version (review [the section below](#make-bump-usage) again)
 14. Fix up the autogenerated changelogs to remove the references to alpha versions and make sure the release version has all changes since the last release
- - Make sure the comparison link is to the latest release verison (e.g.: `compare/v3.11.4...v3.12.0)` instead of `compare/v3.12.0-alpha.1...v3.12.0)`)
- - Delete the sub-sections that relate only to alpha releases, so that the changelog is against the latest actual release
+
+- Make sure the comparison link is to the latest release verison (e.g.: `compare/v3.11.4...v3.12.0)` instead of `compare/v3.12.0-alpha.1...v3.12.0)`)
+- Delete the sub-sections that relate only to alpha releases, so that the changelog is against the latest actual release
+
 15. Do a NORMAL MERGE into `master`. 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):
 
 ```shell
-# note: make sure you have pulled the latest changes for branch 
+# note: make sure you have pulled the latest changes for branch
 # release_${version} locally before merging into master
 git checkout master
 git merge --ff-only release_${version}
 git push origin master
 ```
 
-15. Tag the release: 
+15. Tag the release:
 
 ```shell
 git tag -a v${version} -m 'chore(release): ${version}'
 git push origin v${version}
 ```
 
-16. Open a PR of `master` into `edge`. Give the PR a name like `chore(release): Merge changes from ${version} into edge`. Once it passes, on the command line merge it into `edge`: 
+16. Open a PR of `master` into `edge`. Give the PR a name like `chore(release): Merge changes from ${version} into edge`. Once it passes, on the command line merge it into `edge`:
 
 ```shell
 git checkout edge