# MACI versioning We should establish & document our approach to versioning for the [MACI project](https://github.com/privacy-scaling-explorations/maci). Here are my current thoughts, borrowing largely from @cedoor's [outline for Semaphore](https://hackmd.io/@cedoor/r1SD81cxo). Input welcome! Please comment on this doc or in the [corresponding GitHub issue](https://github.com/privacy-scaling-explorations/maci/issues/807). ## Code MACI code consists of three parts: Circom circuits, Solidity contracts and JS (TS) libraries. ### Circuits Circuits are (ideally) rarely updated, since it would require a new ceremony. Ideally, they should remain the same for years. The MACI circuits are released through the [`@maci-circuits`](https://www.npmjs.com/package/maci-circuits) NPM package. ### Contracts Contracts are updated frequently, however, since each change requires a new deployment, it is recommended to make as few changes as possible. The MACI contracts are released through the [`@maci-contracts`](https://www.npmjs.com/package/maci-contracts) NPM package. ### JS libraries JavaScript libraries are updated very frequently, and this requires no special action other than releasing new versions. The MACI JS libraries are released through the following NPM packages: - [`@maci-cli`](https://www.npmjs.com/package/maci-cli) - [`@maci-common`](https://www.npmjs.com/package/maci-common) - [`@maci-core`](https://www.npmjs.com/package/maci-core) - [`@maci-crypto`](https://www.npmjs.com/package/maci-crypto) - [`@maci-domainobjs`](https://www.npmjs.com/package/maci-domainobjs) - [`@maci-integrationtests`](https://www.npmjs.com/package/maci-integrationtests) - [`@maci-server`](https://www.npmjs.com/package/maci-server) ## Strategy Given that all MACI packages are organized in [our monorepo](https://github.com/privacy-scaling-explorations/maci), I think it makes sense to have a global release approach, where all packages have the same version (it seems [we've already been doing that](https://github.com/privacy-scaling-explorations/maci/releases)). Currently, MACI core team manually decides when to release annd what the version should be. Packages are released [automatically via CI](https://github.com/privacy-scaling-explorations/maci/blob/master/.github/workflows/release.yml) when a new tag is created in GitHub. Could we/should we have a more automated approach, e.g. following SemVer with more automated tools? Or at least a general framework to guide our decision making on how to appropriately tag a release? Main goal here is to set clear expectations for developers using our libraries and to provide a consistent experience. ## Thoughts? Input welcome on this! Thank you in advance 🙏 Particularly interested on ideas for rules around changes to circuits and contracts, e.g. - is ANY change to a circuit considered a breaking change (major release), given that'll require a new ceremony? - if the change concerns a performance improvement but does not change the meaning of the code, maybe it could be a minor one, although a new ceremony is still required - same for smart contracts, given any changes would require a new deploy? Or is only a major change if the contract interface is changed? - any changes would require a new deployment, but perhaps we release minor versions for minor changes on contracts ## Resources - [MACI releases to date](https://github.com/privacy-scaling-explorations/maci/releases)