We should document what steps were taken, who took them, and any comments or concerns raised (e.g. from external security partners) before and during a deployment. This is especially important for smart contract deployments, but could be adapted in a lightweight fashion to also cover frontend changes to aragonPM packages.

An initial list (to be expanded as time goes):

• Repos / contracts to be deployed
  • Functionality delta from previous release (or completely new functionality if no previous deployment)
    • If previous deployment exists, is there an upgrade path and has it been tested?
  • Contract configuration (if parametrizable)
  • State of repo
    • Commit hash
    • Spec status
    • Test status
    • Security review status
• Deployer
  • Permissions required / used

Sign-offs could be done in the form of approvals to an issue made to document the process for the release (e.g. on this repo).

See https://medium.com/the-ethereum-name-service/ens-registry-migration-bug-fix-new-features-64379193a5a

Due to Saint Fame needing NFT support ASAP, they will be performing an upgrade to their Agent instance using this unreleased version:

• Address: 0x3a93c17fc82cc33420d1809dda9fb715cc89dd37
• Commit hash: 3c0ab41572dea3c87ab31fc1011f055c25d4a3c0 (deployed from aragon-apps next)

When we are ready to publish a new version of Agent (which will prompt orgs to upgrade), we should use that address as the contract code so upgraded DAOs get the Agent UI back.

The Agent app IPFS content was published with a lot of irrelevant files. As viewed here.

We could use the same command as in the Vault app and include the relevant metadata at the same time (aragon/aragon-apps#880):

aragon apm publish patch --environment mainnet --files public

Oops, this was forgotten on the 0.7 deployment.

aragonOS

• Merge aragon/aragonOS#551 (@izqui)
• External code review for aragon/aragonOS#551 (won't do)
• Release aragonOS 4.3 (@facuspagnuolo)
• Deploy DAOFactory (@facuspagnuolo)
• Develop proxy versioning oracle (@izqui): https://github.com/aragonone/version-oracle/pull/1
  - [ ] Deploy proxy versioning oracle (@izqui)
• Verify aragonOS mainnet contracts in Etherscan (@izqui)

Templates

• Finish review and merge aragon/dao-templates#150 (@sohkai)
• Staging: publish templates aragon/dao-templates#157 (@facuspagnuolo)
• Rinkeby: publish templates (@izqui)
• Mainnet: publish templates (@izqui)

Client

• Staging: initial release (@sohkai)
• Staging: release candidate (@sohkai)
• Rinkeby: major (?) release (@izqui)
• Mainnet: major (?) release (@izqui)

Apps

Agent

• Staging: major release (@sohkai)
• End to end test on staging (@sohkai, @facuspagnuolo, @izqui)
• Rinkeby: minor release (@izqui)
• Mainnet: major release (@izqui)

Finance, Voting, TM

• Staging: minor releases (@sohkai)
• Rinkeby: minor releases (@izqui)
• Rinkeby: minor releases (@izqui)

I was just looking at the bounties for GoodDollar and I saw one for adding an Aragon fork on fuse.io (an EVM sidechain).
GoodDollar/Bounties#14

The GoodDollar project is pretty big with 58k active users and they are offering a bounty of about 2k usd which could go to the Aragon DAO. An official deployment would be much better than a fork.

If interested, I can send some fuse for gas and if needed I can also deploy the ENS smart contracts on fuse.
https://docs.ens.domains/deploying-ens-on-a-private-chain

Agent v5 currently has initialize() in its deprecatedFunctions declaration, which is a tooling limitation (aragonCLI / buidler unable to understand contract inheritance).

See details in #37; we should put them in the readme.md files :).

Our current MiniMeTokenFactory does not emit events when creating tokens, which makes it difficult to dynamically register new tokens in off-chain tools like subgraphs.

We should redeploy this (and all the templates which use it) to the new version at https://github.com/aragon/minime, which does emit this event.

The ui components of the most recent deployments were not included. This means that the content is not visible when using ipfs to render the ui. The result when running apm versions is

 ℹ voting.aragonpm.eth has 6 published versions
 ✔ 1.0.0: 0xEae3502771635e6270e01f5B859DDB7ed780aebf ipfs:Qmer59t99nhZMk69TZTtXFn3im8uFLjpsLdub7zb75r1vq
 ✔ 1.0.1: 0xEae3502771635e6270e01f5B859DDB7ed780aebf ipfs:QmPQjG4PSPXvhRYzxFBuU7HWSBTjyHL9HfRXapgjQUigkP
 ✔ 1.0.2: 0xEae3502771635e6270e01f5B859DDB7ed780aebf ipfs:QmXkC9JfpR2xUEUYrGdcepjaBGPopd2cNJg2UKDpi8Hmye
 ✔ 1.0.3: 0xEae3502771635e6270e01f5B859DDB7ed780aebf ipfs:QmctB78EiDW5LtSNA2FY8VUDwDWijv54UFDWKBs4a5nvyj
 ✔ 1.0.4: 0xEae3502771635e6270e01f5B859DDB7ed780aebf ipfs:QmcwXZXdbxF5qgKFh66zfZHTXYoUeHT9gtVqn27WMCvxTr
 ✖ 1.0.5: 0xEae3502771635e6270e01f5B859DDB7ed780aebf Version not found in provider

As I had to merge in a hurry to bring up the deployment again

The permanent ENS registrar has been deployed to both Rinkeby and Ropsten, and names can be claimed via https://manager.ens.domains/name/aragonpm.eth

It's a bit of a hassle, but at some point we should redeploy the entire testnet stack such that it's using the real ENS registrar rather than our own.

This would reset all testnet organization's aragonid names, but we could ask them to ping us to recreate the mapping.

A non-essential part of the 0.8 deployments, but one that we should still do.

Having this would allow the frontend to know which proxies are the newer ones that have fixed the SLOAD fallback issue.

As well as document where it is on other environments (e.g. rinkeby and mainnet).

See: aragon/aragon-cli#425 (comment)

And: aragon/aragon.js#273 (comment)