-
- -
@@ -74,72 +35,40 @@ Refer to the Directory Structure section below to understand which packages are └── specs: Specs of the rollup starting at the Bedrock upgrade-## Branching Model - -### Active Branches - -| Branch | Status | -| --------------- | -------------------------------------------------------------------------------- | -| [master](https://github.com/ethereum-optimism/optimism/tree/master/) | Accepts PRs from `develop` when intending to deploy to production. | -| [develop](https://github.com/ethereum-optimism/optimism/tree/develop/) | Accepts PRs that are compatible with `master` OR from `release/X.X.X` branches. | -| release/X.X.X | Accepts PRs for all changes, particularly those not backwards compatible with `develop` and `master`. | - -### Overview - -This repository generally follows [this Git branching model](https://nvie.com/posts/a-successful-git-branching-model/). -Please read the linked post if you're planning to make frequent PRs into this repository. - -### Production branch - -The production branch is `master`. -The `master` branch contains the code for latest "stable" releases. -Updates from `master` **always** come from the `develop` branch. - -### Development branch - -The primary development branch is [`develop`](https://github.com/ethereum-optimism/optimism/tree/develop/). -`develop` contains the most up-to-date software that remains backwards compatible with the latest experimental [network deployments](https://community.optimism.io/docs/useful-tools/networks/). -If you're making a backwards compatible change, please direct your pull request towards `develop`. - -**Changes to contracts within `packages/contracts-bedrock/src` are usually NOT considered backwards compatible and SHOULD be made against a release candidate branch**. -Some exceptions to this rule exist for cases in which we absolutely must deploy some new contract after a release candidate branch has already been fully deployed. -If you're changing or adding a contract and you're unsure about which branch to make a PR into, default to using the latest release candidate branch. -See below for info about release candidate branches. - -### Release candidate branches - -Branches marked `release/X.X.X` are **release candidate branches**. -Changes that are not backwards compatible and all changes to contracts within `packages/contracts-bedrock/src` MUST be directed towards a release candidate branch. -Release candidates are merged into `develop` and then into `master` once they've been fully deployed. -We may sometimes have more than one active `release/X.X.X` branch if we're in the middle of a deployment. -See table in the **Active Branches** section above to find the right branch to target. - -## Releases +1. clone the Github repository and update the submodule. -### Changesets +```sh +cd $HOME +git clone https://github.com/kobakaku/optimism-celestia +cd optimism-celestia +git submodule update --init --recursive +``` -We use [changesets](https://github.com/changesets/changesets) to mark packages for new releases. -When merging commits to the `develop` branch you MUST include a changeset file if your change would require that a new version of a package be released. +2. build app. -To add a changeset, run the command `pnpm changeset` in the root of this monorepo. -You will be presented with a small prompt to select the packages to be released, the scope of the release (major, minor, or patch), and the reason for the release. -Comments within changeset files will be automatically included in the changelog of the package. +```sh +cd $HOME +cd optimism-celestia +make +``` -### Triggering Releases +3. set enviroment variables. -Releases can be triggered using the following process: +```sh +export SEQUENCER_BATCH_INBOX_ADDRESS=0xff00000000000000000000000000000000000000 +export L2OO_ADDRESS=0x70997970C51812dc3A010C7d01b50e0d17dc79C8 +``` -1. Create a PR that merges the `develop` branch into the `master` branch. -2. Wait for the auto-generated `Version Packages` PR to be opened (may take several minutes). -3. Change the base branch of the auto-generated `Version Packages` PR from `master` to `develop` and merge into `develop`. -4. Create a second PR to merge the `develop` branch into the `master` branch. +4. start app. -After merging the second PR into the `master` branch, packages will be automatically released to their respective locations according to the set of changeset files in the `develop` branch at the start of the process. -Please carry this process out exactly as listed to avoid `develop` and `master` falling out of sync. +```sh +make devnet-up +``` -**NOTE**: PRs containing changeset files merged into `develop` during the release process can cause issues with changesets that can require manual intervention to fix. -It's strongly recommended to avoid merging PRs into develop during an active release. +5. view logs (optional). -## License + If you'd like to view the logs of the devnet, run the following command. -All other files within this repository are licensed under the [MIT License](https://github.com/ethereum-optimism/optimism/blob/master/LICENSE) unless stated otherwise. +```sh +make devnet-logs +```