You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-`-a, --add-new-synths` Whether or not any new synths in the synths.json file should be deployed if there is no entry in the config file.
30
30
-`-b, --build-path [value]` Path for built files to go. (default of `./build` - relative to the root of this repo). The folders `compiled` and `flattened` will be made under this path and the respective files will go in there.
31
31
-`-c, --contract-deployment-gas-limit <value>` Contract deployment gas limit (default: 7000000 (7m))
32
-
-`-d, --deployment-path <value>` Path to a folder that has your input configuration file (`config.json`), the synths list (`synths.json`) and where your `deployment.json` file will be written (and read from if it currently exists). The `config.json` should be in the following format ([here's an example](deployed/goerli/config.json)):
32
+
-`-d, --deployment-path <value>` Path to a folder that has your input configuration file (`config.json`), the synths list (`synths.json`) and where your `deployment.json` file will be written (and read from if it currently exists). The `config.json` should be in the following format ([here's an example](deployed/sepolia/config.json)):
For `synthetix` repo, we are using the following branch mapping:
167
167
168
-
-`alpha` is `GOERLI`
168
+
-`alpha` is `sepolia`
169
169
-`master` is `MAINNET`
170
170
171
-
PRs should start being merged into `develop` then deployed onto `GOERLI`, then merged into `staging` once deployed for releasing onto `goerli` for staging into a `mainnet` release. These can be done multiple times for each branch, as long as we keep these up to date.
171
+
PRs should start being merged into `develop` then deployed onto `sepolia`, then merged into `staging` once deployed for releasing onto `sepolia` for staging into a `mainnet` release. These can be done multiple times for each branch, as long as we keep these up to date.
172
172
173
173
### Versioning
174
174
@@ -178,12 +178,12 @@ Using semantic versioning ([semver](https://semver.org/)): `v[MAJOR].[MINOR].[PA
178
178
-`MINOR` are any changes to the underlying Solidity contracts
179
179
-`PATCH` are for any JavaScript or deployed contract JSON changes
180
180
-`ADDITIONAL` are for testnet deployments
181
-
-`-alpha` is for `Goerli`
181
+
-`-alpha` is for `sepolia`
182
182
183
183
### Examples
184
184
185
185
- Say `v3.1.8` is a mainnet release
186
-
-`v3.1.9-alpha` is a Goerli deployment of new synths (no contract changes)
186
+
-`v3.1.9-alpha` is a sepolia deployment of new synths (no contract changes)
187
187
-`v3.1.9` is the mainnet release with all environments
- Any PRs that involve a SIP must always add an entry to `sips` list.
212
-
- However they should never allocate a SIP to a release (in `releases` list) - this is done once we are ready to promote a release to Goerli (and thus staging), this way, your PRs are disconnected from releases as they should be.
212
+
- However they should never allocate a SIP to a release (in `releases` list) - this is done once we are ready to promote a release to sepolia (and thus staging), this way, your PRs are disconnected from releases as they should be.
0 commit comments