Update contracts release documentation

packages/contracts-bedrock/book/src/SUMMARY.md

@@ -11,5 +11,4 @@
 # Policies
 
 - [Solidity Upgrades](./policies/solidity-upgrades.md)
-- [Code Freezes](./policies/code-freezes.md)
-- [Versioning](./policies/versioning.md)
+- [Versioning](./policies/versioning.md)

packages/contracts-bedrock/book/src/policies/release-process.md

@@ -0,0 +1,56 @@
+# Tagging and Release Process
+
+## Creating a tagged release
+
+First select a tag string based on the guidance in [Monorepo Contracts Release Versioning](./versioning.md#monorepo-contracts-release-versioning)
+
+1. Checkout the commit
+1. Run `git tag <tag-string>`
+1. Run `git push origin <tag-string>`
+   This may require special authorization. Once pushed a tag cannot be deleted, so please be sure it is correct.
+1. Create release notes in Github:
+   - Go to the [Releases page](https://github.com/ethereum-optimism/optimism/releases), enter or select `<tag-string>`
+     from the dropdown.
+1. Populate the release notes. If the tag is a release candidate, check the `Set as a pre-release`  option, and uncheck the
+   `Set as the latest release` option.
+1. Deploy the OPCM using the `op-deployer bootstrap implementations` [command](https://devdocs.optimism.io/op-deployer/user-guide/bootstrap.html),
+   this will write the addresses of the deployed contracts to `stdout` (or to disk if you provide an `--outfile` argument).
+   Do this on both Sepolia and Mainnet.
+1. In the superchain-registry edit the following files to add a new `[<tag-string>]` entry, with the addresses from the
+   previous step:
+   - [standard-versions-mainnet.toml](https://github.com/ethereum-optimism/superchain-registry/blob/main/validation/standard/standard-versions-mainnet.toml)
+   - [standard-versions-sepolia.toml](https://github.com/ethereum-optimism/superchain-registry/blob/main/validation/standard/standard-versions-sepolia.toml)
+1. Once the changes are merged into the superchain-registry, you can follow the [instructions](https://devdocs.optimism.io/op-deployer/reference-guide/releases.html#step-3-update-the-sr-with-the-new-release)
+   for creating a new release of `op-deployer`.
+
+## Implications for audits
+
+The process above should be followed to create an `-rc.1` release prior to audit. This will be the target commit for
+the audit. If any fixes are required by the audit results an Additional Release Candidate will be required.
+
+## Additional Release Candidates
+
+Sometimes fixes or additional changes need to be added to a release candidate version. In that case
+we want to ensure fixes are made on both the release and the trunk branch, without stopping development
+efforts on the trunk branch.
+
+The process is as follows:
+
+1. Make the fixes on `develop`. Increment the contracts semver as normal.
+1. Create a new release branch, named `proposal/op-contracts/X.Y.Z` off of the rc tag (all subsequent `-rc` tags
+   will be made from this branch).
+1. Cherry pick the fixes from `develop` into that branch. Instead of incrementing the semver as normal,
+   append `-patch.n` to the end of the version number. The value of `n` should start at 1 and be
+   incremented for each additional patch. This suffix prevents a situation where two different implementations of the same
+   contract have the same semver.
+1. After merging the changes into the new release branch, tag the resulting commit on the proposal branch as `op-contracts/vX.Y.Z-rc.n`.
+   Create a new release for this tag per the instructions above.
+
+## Finalizing a release
+
+Once a release has passed governance, a new tag should be created without the `-rc.n` suffix. To do this follow the
+instructions in "Creating a tagged release" once again. It should not be necessary to redeploy the contracts with `op-deployer`,
+but a new entry will be required in the superchain-registry's toml files regardless.
+When creating release notes, _uncheck_ the `Set as a pre-release`  option, and _check_ the
+   `Set as the latest release` option.
+

packages/contracts-bedrock/book/src/policies/versioning.md

@@ -79,41 +79,3 @@ Versioning for monorepo releases works as follows:
 The [OPCM](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L1/OPContractsManager.sol) is the contract that manages the deployment of all contracts on L1.
 
 The `OPCM` is the source of truth for the contracts that belong in a release, available as on-chain addresses by querying [the `getImplementations` function](https://github.com/ethereum-optimism/optimism/blob/4c8764f0453e141555846d8c9dd2af9edbc1d014/packages/contracts-bedrock/src/L1/OPContractsManager.sol#L1061).
-
-## Release Process
-
-When a release is proposed to governance, the proposal includes a commit hash, and often the
-contracts from that commit hash are already deployed to mainnet with their addresses included
-in the proposal.
-For example, the [Fault Proofs governance proposal](https://gov.optimism.io/t/upgrade-proposal-fault-proofs/8161) provides specific addresses that will be used.
-
-To accommodate this, once contract changes are ready for governance approval, the release flow is:
-
-1. Go to https://github.com/ethereum-optimism/optimism/releases/new
-2. Enter the release title as `op-contracts/vX.Y.Z-rc.1`
-3. In the "choose a tag" dropdown, enter the same `op-contracts/vX.Y.Z-rc.1` and click the "Create new tag" option that shows up
-4. Populate the release notes.
-5. Check "set as pre-release" since it's not yet governance approved
-6. Uncheck "Set as the latest release" and "Create a discussion for this release".
-7. Click publish release.
-8. After governance vote passes, edit the release to uncheck "set as pre-release", and remove the `-rc.1` tag.
-
-Although the tools exist to apply a [code freeze](./code-freezes.md) to specific contracts, this is
-discouraged. If a change is required to a release candidate after it has been tagged, the
-[Additional Release Candidates](#additional-release-candidates) for more information on this flow.
-
-### Additional Release Candidates
-
-Sometimes fixes or additional changes need to be added to a release candidate version. In that case
-we want to ensure fixes are made on both the release and the trunk branch, without stopping development
-efforts on the trunk branch.
-
-The process is as follows:
-
-1. Make the fixes on `develop`. Increment the contracts semver as normal.
-2. Create a new release branch, named `proposal/op-contracts/X.Y.Z` off of the rc tag.
-3. Cherry pick the fixes from `develop` into that branch. Instead of incrementing the semver as normal,
-   append `-patch.n` to the end of the version number. The value of `n` should start at 1 and be
-   incremented for each additional patch.
-4. After merging the changes into the new release branch, tag the resulting commit on the proposal branch as `op-contracts/vX.Y.Z-rc.n`.
-   Create a new release for this tag per the instructions above.