docs: move release instructions to Storybook

.storybook/guides/releasing.mdx

@@ -0,0 +1,65 @@
+import { Meta, Title } from '@storybook/blocks';
+
+<Meta title="Guides/Release workflow" />
+
+<Title>Release workflow</Title>
+
+## Versioning
+
+This project versions components independently, meaining each component has its own version number, updated independently of other components. We follow [semantic versioning](https://semver.org/) and as such, each release is versioned according to the following rules:
+
+- **Major**: Breaking changes such as API changes or removal of features
+- **Minor**: New features or enhancements
+- **Patch**: Bug fixes or minor improvements
+
+Versioning is handled by a combination of [conventional commits]() and [Lerna](), which together, automatically update the version number of a component when it is released. This is done by analyzing the commit history and determining the type of changes that have been made. For example, if a commit message contains the word `fix`, Lerna will automatically bump the patch version of the component. If the commit message contains the word `feat`, Lerna will bump the minor version. If the commit message contains the word `BREAKING CHANGE`, Lerna will bump the major version.
+
+## Tooling
+
+Releasing individual components is handled by Lerna. When any component or its dependencies change, Lerna will queue that component (and all of its dependents) up for a release.
+
+To release everything that has changed, run:
+
+```shell
+yarn release
+```
+
+This command runs a cache clear and full build of all components and the ui-icons package before kicking off `lerna publish --no-private` under the hood. Lerna publish evaluates all changed components and prompts to the command line for approval before publishing to NPM. Version numbers are automatically determined, changelogs generated, and then packages are published. Lerna is configured in the `lerna.json` file found in the root of the monorepo.
+
+## Prereleases
+
+Occasionally, it can be helpful for downstream consumers to test changes before they're ready for a stable release. To facilitate this, we can publish prerelease versions. Prereleases are published to the `beta` dist-tag on NPM, and can be installed by consumers using the `@beta` tag. To publish a prerelease:
+
+1. Ensure you're working on a branch other than `main`.
+2. Once your change(s) are ready to be committed, be aware of the severity of the change(s) and be sure to author your commit message so that Lerna understands how to increase the version number(s) of the affected components.
+3. Once your changes are committed, you **must** build the affected package(s) locally **before** publishing them to npm. An npm task for cleaning, building, and beta publishing is available. This command will perform a full clean of the affected directories, a full build of the compiled assets, and will attempt to bump the version numbers in the affected package(s) (via `lerna publish --conventional-prerelease --preid beta --pre-dist-tag beta --no-private`). Run the following command to publish a beta release:
+  ```shell
+  yarn release:beta-from-package
+  ```
+4. Before publishing to npm, Lerna will show a preview of the affected package version numbers that look something like: `@spectrum-css/tag: 3.3.8 => 3.3.9-beta.0`. You will be asked to confirm and continue with publishing the changes or cancel.
+5. At this time, open the `dist` directory of the affected package(s) and ensure that the contents are as expected. If everything looks good, select `y` to publish the affected package(s) to npm. If the `dist` directory is not as expected or assets appear to be missing, select `n` to cancel the release and address the issue(s) before trying again.
+6. Selecting `y` to publish will publish the affected package(s) to npm with the `beta` dist-tag. You should see a summary of the published assets from Lerna and a message confirming successful publication.
+7. Be sure to communicate the availability of the beta release to any consumers who may be interested in testing the changes. Consumers can install the beta release by running `npm install @spectrum-css/<package>@beta` or `yarn add @spectrum-css/<package>@beta`.
+
+## Manual versioning and publishing
+
+In some cases, you may need to manually version and publish a package. This is typically only necessary when a package has been updated in a way that Lerna does not understand, such as when a package has been updated in a way that does not trigger a version bump or when you want to prevent consuming packages from receiving version bumps as well.
+
+This workflow is not recommended for general use, as it can lead to confusion and inconsistency in versioning. It should only be used when absolutely necessary and with caution. It's also a helpful approach to use when resolving a previously failed Lerna command as often Lerna leaves a subset of packages in a half-published state when it runs into errors.
+
+To manually version and publish a package:
+
+1. Ensure you're working on a branch other than `main`.
+2. Manually update the version number in the `package.json` file of the affected package(s). Be sure to follow [semantic versioning](https://semver.org/) when updating the version number. For example, to release a manual beta version, you might update the version number from `3.3.8` to `3.3.9-beta.0`.
+3. Save and commit your changes with an appropriate conventional commit message. For example, `chore(release): manually version @spectrum-css/<package> for beta release`.
+4. Once your changes are committed, you **must** build the affected package(s) locally **before** publishing them to npm. To manually build only a specific package, run the following command:
+  ```shell
+  yarn builder <package> --skip-nx-cache --verbose
+  ```
+5. Once the affected package(s) are built, confirm the results in the `dist` directory of the affected package(s). If everything looks good, you can publish the affected package(s) to npm.
+6. To manually publish a package, run the following command:
+  ```shell
+  yarn lerna publish from-package
+  ```
+7. Follow the prompts to confirm and continue with publishing the changes or cancel. If you choose to continue, expect the affected package(s) to be published to npm with the version number(s) you manually set in the `package.json` file.
+8. Communicate the availability of the new release to any consumers who may be interested in testing the changes. Consumers can install the manual release by running `npm install @spectrum-css/<package>@<version>` or `yarn add @spectrum-css/<package>@<version>`.

README.md

@@ -6,7 +6,6 @@ Spectrum CSS provides a standard CSS implementation of the Spectrum design langu
 1. [Where is the JavaScript?](#where-is-the-javascript)
 1. [Using Spectrum CSS](#using-spectrum-css)
 1. [Contributing](#contributing)
-1. [Releasing](#releasing)
 
 ## Show me a demo
 
@@ -366,49 +365,12 @@ The following tasks are available:
 - `yarn dev` - Performs a component build, runs storybook, and serves the documentation on the default port (3000), then starts watching components and website files
 - `yarn clean` - Cleans all output files for the project and all components
 
----
-
-## Releasing
-
-### Releasing individual components
-
-Releasing individual components is handled by Lerna. When any component or its dependencies change, Lerna will queue that component (and all of its dependents) up for a release.
-
-To release everything that has changed, simply run:
-
-```shell
-yarn release
-```
-
-Version numbers are automatically determined, changelogs generated, and packages published.
-
 ### Releasing the website
 
-After performing a release, run the following command to release the website:
+To publish the latest version of the website, run the following command:
 
 ```shell
-yarn release:docs
+yarn release:site
 ```
 
-### Publishing prereleases
-
-Occasionally, it can be helpful for our subscribers to test CSS changes before they're considered ready to be part of a stable release. To facilitate this, we can publish prerelease versions.
-
-To publish prerelease versions:
-
-- First, be sure that you're working on a branch other than `main`.
-- Once your change(s) are ready to be committed, be aware of the severity of the change(s), and be sure to author your commit message so that Lerna understands how to increase the version number(s) of the affected components.
-- Once your changes are committed, you **must** build the affected package(s) locally **before** publishing them to npm. An npm task for cleaning, building, and beta publishing is available, and it can be run via the following command: `yarn release:beta-from-package`. This command will perform a full `clean` (via the `clean` task), a full `build` (via the `build` task), and will attempt to bump the version numbers in the affected package(s) (via `lerna publish --conventional-prerelease --preid beta --pre-dist-tag beta --no-private`).
-- Depending on the severity of your change(s), and before publishing to npm, Lerna should show a preview of the affected package version numbers that look something like: `@spectrum-css/tag: 3.3.8 => 3.3.9-beta.0`. Additionally, at this time, Lerna will ask if you would like to continue with publishing the changes or cancel.
-- Selecting `y` to publish will publish the affected package(s) to npm.
-
-### Manual prerelease versioning & publishing
-
-Occasionally, you may want to run a prerelease for an individual package and skip a version bump for consuming packages. It's possible to manually change a package's version number to achieve this.
-
-- For the package that you want to prerelease, manually alter the version number in the package's `package.json` file.
-  - For example, let's say you'd like to release a `beta` version of the Switch component. In the Switch's `package.json`, manually change the `version` number from its current number (`"version": "1.0.23"`) to the next appropriate semver version number (`"version": "2.0.0-beta.0"`).
-- Save your changes, and commit them with the appropriate conventional commit-style commit message: `chore(switch): manual version bump for beta release` or something similar.
-- You **must** run a build **before** continuing with the prerelease. An npm task for cleaning, building, and beta publishing is available, and it can be run via the following command: `yarn release:beta-from-package`. This command will perform a full `clean` (via the `clean` task), a full `build` (via the `build` task), and will attempt to publish the package (via `lerna publish --conventional-prerelease --preid beta --pre-dist-tag beta --no-private`).
-- Depending on the severity of your change(s), and before publishing to npm, Lerna should show a preview of the affected package version number that looks something like: `@spectrum-css/switch: 1.0.23 => 2.0.0-beta.0`. Additionally, at this time, Lerna will ask if you would like to continue with publishing the changes or cancel.
-- Selecting `y` to publish will publish the affected package(s) to npm.
+This will build the website and all dependent assets and push the changes to the `gh-pages` branch. From there, an organizational hook will pick up the changes and publish them to [https://opensource.adobe.com/spectrum-css/](https://opensource.adobe.com/spectrum-css/); they should be available after a few minutes.