docs: Update release process documentation (#1656)

share/doc/wake/how-to/create-a-release.adoc

@@ -17,75 +17,55 @@ $ git pull origin master
 $ git checkout -b release-0.15.3
 ----
 
-3. If the release will add to or otherwise change the public exports of the `wake` package interface, (re)generate the versioned package.
-   If it doesn't, go to step 6.
-+
-[source,shell]
-----
-$ ./bin/wake --in wake --export-api v0_15_wake > share/wake/lib/versions/v0_15.wake
-----
-
-4. Open the previous versioned package in a text editor.
-   If the export lines export from `wake` rather than the current versioned package, change each of them to export from that current package instead.
-   For example, `from wake export type binary ; =>` should become `from v0_15_wake export type binary ; =>`.
-
-5. Commit the changes to the versioned package(s).
-+
-[source,shell]
-----
-$ git add share/wake/lib/versions/v0_14.wake share/wake/lib/versions/v0_15.wake
-$ git commit -m "Pin the 0.15 public API."
-----
-
-6. Open `debian/changelog.in` in a text editor.
+3. Open `debian/changelog.in` in a text editor.
    Check to see whether the top-most release note corresponds to the previous release or whether it is a placeholder for the next release.
    If you see the previous release's version number in the release note second from the top, then the top-most release note is a placeholder for the next release. In this case, go to step 5.
    If instead it looks like the top-most release _is_ the previous release, then go to step 4.
 
-7. Create a copy of the top-most release note immediately below it.
+4. Create a copy of the top-most release note immediately below it.
    In the second instance, replace the `@VERSION@` string with the actual version number of the previous release.
 
-8. Update the top-most release note to contain the actual release information.
+5. Update the top-most release note to contain the actual release information.
    Update the text to describe the release itself.
    Update the author, email, and the release date to match the actual release information.
 
-9. Commit the changes to `changelog.in`.
+6. Commit the changes to `changelog.in`.
 +
 [source,shell]
 ----
 $ git add debian/changelog.in
 $ git commit -m "Set release date."
 ----
 
-10. Push the branch to GitHub.
+7. Push the branch to GitHub.
 +
 [source,shell]
 ----
 $ git push origin release-0.15.3
 ----
 
-11. Open a pull request on GitHub. Make sure you set the base branch to `master`.
+8. Open a pull request on GitHub. Make sure you set the base branch to `master`.
 
-12. Merge the release into master after CI passses and PR is approved.
+9. Merge the release into master after CI passses and PR is approved.
 
-13. Checkout master and update to the release commit
+10. Checkout master and update to the release commit
 +
 [source,shell]
 ----
 $ git checkout master
 $ git pull origin master
 ----
 
-14. Create a tag with the version string you want to use, e.g. `v0.15.3`, and push the tag to GitHub.
+11. Create a tag with the version string you want to use, e.g. `v0.15.3`, and push the tag to GitHub.
 +
 [source,shell]
 ----
 $ git tag v0.15.3
 $ git push origin v0.15.3
 ----
 
-15. After the tagged is pushed, the release workflow will automatically generate a GitHub draft release.
+12. After the tagged is pushed, the release workflow will automatically generate a GitHub draft release.
     Wait for the release to be created then download the vsix artifact and upload it to the MS marketplace
     The update link is here: https://marketplace.visualstudio.com/manage/publishers/sifive
 
-16. Finalize the release copy and publish.
+13. Finalize the release copy and publish.