Skip to content

How tos

Jump to bottom
Gareth Fuller edited this page Mar 14, 2023 · 33 revisions

A collection of guides for specific types of contributions.

Full release

A full release is a release that syncs develop with master. Full releases typically happen on a weekly release cycle which happens every Monday.

To perform a full release, follow this process:

  1. Make sure you have the latest changes on develop: git checkout develop && git pull
  2. Determine what the next version should be. It should usually be a minor version bump. So if the version is currently 1.2.4 the next version should be 1.3.0 etc.
  3. Branch off develop: git checkout -b release/X.X.X
  4. Merge master into this branch (in case anything was merged into master that wasn't merged into develop): git fetch && git merge origin/master
  5. Ensure all issues in this weeks testing document are addressed.
    • Make any changes or fixes required locally.
    • Stage & commit your changes: git commit -am "Describe your change"
  6. Increase the app's minor version in package.json to the same version as the branch with npm version minor
  7. Push your branch to github git push origin HEAD and create a PR with master as a title of Release X.Y.Z and a body of Weekly Release
  8. Wait for checks to pass and ask for approval. The version check currently always fails with a minor version bump so you can ignore that.
  9. Once approved, change the merge type to "Create a Merge commit" and then merge your PR with master. It needs to be a merge commit to keep master and develop in sync.
  10. Create a new PR with your release branch but now set the base (the branch you want to merge into) to develop. Set the body of this PR to Original: #XYZ pointing to your last PR.
  11. After approvals, change the merge type to "Create a Merge commit" and merge your release into develop.
  12. Draft a new release setting the release version and title of the release to the version number you set in step 4 (make sure to set the release target as master).
  13. Add a description for your release that is similar in structure to previous full releases.
  14. Publish your release.

Hotfix release

A hotfix release is a release straight to the master branch and therefore an immediate deployment to the production apps. Hotfixes are for when something needs to go live before the next weekly release cycle which happens every week on a Monday.

To perform a hotfix, follow this process:

  1. Make sure you have the latest changes on master: git checkout master && git pull
  2. Branch off master: git checkout -b hotfix/title-of-fix
  3. Make your changes locally.
  4. Stage & commit your changes: git add -A && git commit -m "Describe your change"
  5. Increase the app's patch version in package.json. e.g. If the version is x.x.1 then change to X.X.2
  6. Run npm install: npm install
  7. Stage & commit the version update: git add -A && git commit -m "Bump version"
  8. Push your branch to github and create a PR.
  9. Once approved, merge your PR with master.
  10. Create a new PR with your hotfix branch but now set the base (the branch you want to merge into) to develop.
  11. After approvals, merge your hotfix into develop.
  12. Draft a new release setting the release version and title of the release to the version number you set in step 4 (make sure to set the release target as master).
  13. Add a description for your hotfix that is similar in structure to previous hotfix releases.
  14. Publish your release.

Add Stable pool to allowlist

  1. If you're not a core repo contributor, create a pull request from a fork. If you are a core contributor follow the hotfix release process.
  2. Add your pool ID to the relevant network allowlist: Mainnet, Polygon or Arbitrum
  3. Stage & commit that change: git commit -m "Add my stable pool to allowlist"
  4. Increase the app's patch version in package.json. e.g. If the version is x.x.1 then change to x.x.2
  5. Run npm install: npm install
  6. Stage & commit the version update: git commit -m "Bump version"
  7. Push your branch to github and create a PR.
  8. Request a review from a couple of core team members.

If the PR looks good, a core team member will merge with the master branch and run through the hotfix release process.

Add a new voting gauge

  1. If you're not a core repo contributor, create a pull request from a fork. If you are a core contributor follow the hotfix release process.
  2. Add the pool ID and network to the appropriate array in voting-gauge-pools.ts (Mainnet, Arbitrum & Polygon)
  3. Set an environment variable with an Infura key: export VUE_APP_INFURA_PROJECT_ID=<YOUR_KEY>
  4. Run the voting gauge generation script: npm run generate:voting-gauges
  5. Add the pool ID to the relevant stakable allowlist array: Mainnet, Polygon or Arbitrum
  6. Stage & commit these changes: git commit -m "Update voting gauge list" (please avoid staging your change to .env.development)
  7. Increase the app's patch version in package.json. e.g. If the version is x.x.1 then change to x.x.2
  8. Run npm install: npm install
  9. Stage & commit the version update: git commit -m "Bump version"
  10. Push your branch to github and create a PR.
  11. Request a review from a couple of core team member.

If the PR looks good, a core team member will merge with the master branch and run through the hotfix release process.

Support a new network

Reference PR: https://github.com/balancer-labs/frontend-v2/pull/1957

Required information before starting

  • chainId, name, token data
  • explorer url, name
  • RPC url
  • subgraph urls
  • contract addresses
  • pool, gauge and tokenlists

Update external repositories:

  • balancer-labs/balancer-sor - addresses, consts, etc.
  • balancer-labs/balancer-sdk - network type, pools, tokens, etc.

Update basic information:

  • README.md - add in "Available networks:"
  • src/assets/images/icons/networks/ - add network svg icon

Create json file with network data

  • src/lib/config/.json - add network information

Update constants:

  • src/contants/initialTokens.json - add network id
  • src/constants/pools.ts - add network pools information (POOLS_<NETWORK_NAME>)
  • src/constants/tokenlists.ts - add tokenlist urls
  • src/constants/tokens.ts - add tokens information
  • src/constants/voting-gauges.ts - add voting gauge information
  • src/constants/voting-gauge-pools.ts - add voting gauge pool information
  • src/constants/rateProviders.ts - allowed rate providers

Update composables:

  • src/composables/useBlockative.ts - add to const SUPPORTED_NETWORKS
  • src/composables/useNetwork.ts (add const is<Network>, add to function networkFor, add to function subdomainFor)
  • src/composables/usePoolWarninig.ts - add to const POOL_ISSUES
  • src/composables/useSnapshots.ts - add to function blockTime
  • src/composables/useVeBAL.ts - check if veBal supported on new network
  • src/composables/useBotingGauges.ts - add to const _votingGauges

Update services and scripts:

  • src/services/web3/useWeb3.ts - add const is<Network-name>
  • src/services/web3/web3.plugin.ts - networkMap
  • src/services/coingecko/coingecko.service.ts - add to const getNativeAssetId and const getPlatformId
  • src/services/balancer/gauge/gauge-controller.decorator.ts - check private getNetwork
  • src/lib/scripts/voting-gauge.generator.ts - add to function getTrustWalletAssetsURI and check function getGaugeAddress
  • src/services/gas-price/gas-price.service.ts - gas price provider

Update other config files:

  • src/lib/balancer.sdk.ts - add to const network
  • src/lib/config/index.ts - add to const config
  • src/plugins/sentry.ts - add to const networkMap

Update vue components:

  • src/components/cards/TradeCard/TradeRoute.vue - add to const prefixMap
  • src/components/navs/AppNav/AppNavNetworkSelect.vue
  • src/components/links/BridgeLink.vue

Set up Vercel domain and deployments.

https://vercel.com/balancer

Clone this wiki locally