# Semaphore versioning

## Code

Semaphore code consists of three parts: Circom circuits, Solidity contracts and JavaScript libraries.

### Circuits

Circuits are very rarely updated, since it would require a new ceremony. Ideally, they should remain the same for years.

The Semaphore circuits have no packages. They are not distributed but anyone can see the code in our [repository](https://github.com/semaphore-protocol/semaphore/tree/main/circuits) and the [Trusted Setup data](https://storage.googleapis.com/trustedsetup-a86f4.appspot.com/semaphore/semaphore_top_index.html).

### Contracts

Contracts are updated quite frequently. However, since each change requires a new deployment and old on-chain groups would be lost, it is recommended to make as few changes as possible.

One long-term solution might be to use a Proxy pattern, so as to fix bugs and make minor improvements while keeping the same address and storage with the same groups.

The Semaphore contracts are released through the `@semaphore-protocol/contracts` NPM package.

### JS libraries

JavaScript libraries are updated very frequently, and this requires no special action other than releasing new versions.

The Semaphore JS libraries are released through the following NPM packages: `@semaphore-protocol/group`, `@semaphore-protocol/identity`, `@semaphore-protocol/subgraph`, `@semaphore-protocol/proof`.

## Strategy

### Repository

Semaphore libraries are organized in a monorepo, while contracts and circuits are in a separate repository. The long-term goal is to have a **single monorepo for all code**.

### Versioning

Regarding versioning strategies, there are mainly 3:

1. Semantic Release Versioning: fully automated versioning method with Conventional Commits;
2. Manual Versioning: developer and maintainers are in charge of changing the versions;
3. Global Versioning: all of the packages and services have the same version.

Of course, these strategies can also be mixed.

Currently, Semaphore does not use any automatic versioning tools, and path and minor versions of packages are handled separately and manually. Instead, major versions are released globally.

Once a single monorepo is configured, the goal is to set up an **automated versioning tool** and move to a **global release approach**, where all packages have the same version.

### Audits

The most sensitive part to check is certainly the contracts. Internal audits could cover minor versions where there are changes related to contracts, while external audits could cover major versions, which will typically be non-backward compatible changes to contracts.

###### tags: `semaphore`