Disable automatic docs generation; add to release process (fixes #1397).

CONTRIBUTING.md

@@ -106,11 +106,15 @@ Before a release can be made, some planning is required:
 A series of Release Candidates should be created and tested to ensure that the final release is stable. Note that the examples in the steps below assume that Git is set up with an `upstream` remote pointing at the main Universal Viewer repository and an `origin` remote pointing at the Release Manager's fork. Replace X.Y.Z in all steps with the version determined in step 2 of Pre-Release Planning.
 
 1. When it's time to begin the release process, the Release Manager will create a `release-X.Y.Z` branch off of `dev`: `git checkout dev ; git checkout -b release-X.Y.Z ; git push --set-upstream upstream release-X.Y.Z`
-2. The Release Manager should next create a pull request against the new branch containing the result of using NPM to bump the version: `git checkout -b release-X.Y.Z-rc1 ; npm version X.Y.Z-rc1 ; git push --set-upstream origin release-X.Y.Z-rc1`. When creating the PR on GitHub, be sure that you target the appropriate release branch, not `dev`. This PR can be merged immediately; its purpose is to create an easily accessible public preview and a public forum for discussion of the RC. The description of this pull request should highlight major changes and areas where testing is needed; you can use the GitHub compare tool to review commits -- e.g. `https://github.com/UniversalViewer/universalviewer/compare/main...release-X.Y.Z` will show all commits added between the last stable release and the new release-in-progress.
-3. The release tag created during step 2 should be pushed to the main GitHub repository to trigger publishing of the release candidate to NPM: `git push upstream vX.Y.Z-rc1`
-4. Next, the Steering Group will announce the release candidate and offer an appropriate testing window (usually 1-2 weeks, depending on scope/complexity of changes) for community feedback. During this window, community members are encouraged to build the new version, try it out in their environments, and raise issues/pull requests if they encounter problems.
-5. If problems were found during the testing window, they will be evaluated by the Steering Group, and as soon as any critical bugs are fixed, steps 1-4 will be repeated with an incremented "rc" number (e.g. X.Y.Z-rc2) to ensure that no problems remain.
-6. Once the release candidate is deemed stable by the Steering Group, it will be promoted to the formal release. After the RC pull request is merged, the full release can be published.
+2. The Release Manager should create a new branch for the release candidate: `git checkout -b release-X.Y.Z-rc1`.
+3. The Release Manager should use NPM to bump the version: `npm version X.Y.Z-rc1`.
+4. The Release manager should ensure that auto-generated documentation is up to date by running `npm run docs` and committing changes, if any.
+5. The Release Manager should push the new RC branch up to their personal repo: `git push --set-upstream origin release-X.Y.Z-rc1`.
+6. The Release Manager should next create a pull request to merge `release-X.Y.Z-rc1` into the new `release-X.Y.Z` branch. When creating the PR on GitHub, be sure to target the appropriate release branch, not `dev`. This PR can be merged immediately; its purpose is to create an easily accessible public preview and a public forum for discussion of the RC. The description of this pull request should highlight major changes and areas where testing is needed; you can use the GitHub compare tool to review commits -- e.g. `https://github.com/UniversalViewer/universalviewer/compare/main...release-X.Y.Z` will show all commits added between the last stable release and the new release-in-progress.
+7. The release tag created during step 2 should be pushed to the main GitHub repository to trigger publishing of the release candidate to NPM: `git push upstream vX.Y.Z-rc1`
+8. Next, the Steering Group will announce the release candidate and offer an appropriate testing window (usually 1-2 weeks, depending on scope/complexity of changes) for community feedback. During this window, community members are encouraged to build the new version, try it out in their environments, and raise issues/pull requests if they encounter problems.
+9. If problems were found during the testing window, they will be evaluated by the Steering Group, and as soon as any critical bugs are fixed, steps 2-8 will be repeated with an incremented "rc" number (e.g. X.Y.Z-rc2) to ensure that no problems remain.
+10. Once the release candidate is deemed stable by the Steering Group, it will be promoted to the formal release. After the RC pull request is merged, the full release can be published.
 
 ### Making a Normal Release