Skip to content

How tos

Jump to bottom
Tritium edited this page Aug 8, 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.
  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 Release X.Y.Z (DM) as title. 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. Push your branch to Github and create a PR.
  6. Once approved, merge your PR with master.
  7. Create a new PR with your hotfix branch but now set the base (the branch you want to merge into) to develop.
  8. After approvals, merge your hotfix into develop.
  9. Draft a new release setting the release version and title of the release to the latest version number.
  10. Add a description for your hotfix that is similar in structure to previous hotfix releases.
  11. Publish your release.

Add a new pool

Once a pool has been created there are two steps required to allow liquidity provision through the Balancer UI. In most cases pool creation triggers an automatic review/whitelist process. If this is a new pool, you could try waiting 4-8 hours before going through the process of creating whitelist PR yourself. The steps below may be followed to create a manual request to integrate tokens into the UI. We are also very open to helping with token/pool integrations on our Discord.

  1. Add the pool ID to the frontend allowlist.
  2. Add the pool tokens to the balancer Tokenlist that are not already included.

Add pool ID to allowlist

  1. If you're not a core repo contributor, create a pull request from a fork. Make sure to branch off the master branch.
  2. Add your pool ID to the relevant network allowlist, e.g. src/lib/config/mainnet/pools.ts In pools.ts there are separate allowlists for Stable and Weighted pools, for example, if your pool is a Weighed pool add your ID to the Weighted.Allowlist array.
  3. Commit those changes.
  4. Push your branch to github and create a PR.
  5. Request a review from a couple of core team members.

Add tokens to Tokenlist

  1. If you're not a core repo contributor, create a pull request from a fork on our Tokenlists repo.
  2. Add the token address to the relevant network array in src/tokenlists/balancer/tokens.ts
  3. Push your branch to github and create a PR.
  4. Request a review from a couple of core team members.

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. Push your branch to github and create a PR.
  8. 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.

Clone this wiki locally