Versioning Contracts

When you add a repo, we compile and import all of its contracts. You may not care about some of them, e.g. mock testing contracts. In the repository’s contracts section, you can toggle the contract off. This removes its workspace (it can be added back at any time however).

When developing a smart contract, you’ll typically start with an initial version and deploy it to a testnet. As you make changes to the contract’s logic, each modification creates a new version of that contract. You might then deploy this updated version multiple times for testing or validation.

The Stagenet organizes your project’s smart contracts according to this flow. Each contract is treated as an isolated entity, with its own Contract Workspace and a history of unique Versions, each of which can have multiple Deployments. It does all this completely automatically by linking to a GitHub repository containing those contracts.

Each Contract Workspace has a Version and Deployment Manager that displays all of its Versions and Deployments. Use it to browse the contract’s history, view details, and switch between different Versions or Deployments.

Versions

Each contract in your project is made up of a history of Versions. A Version is defined by unique contract’s bytecode — typically tied to a specific Solidity file.

When you link your Stagenet to a GitHub repository, each imported contract gets a new Contract Workspace with an initial Version matching the contract’s code at the time of import. Note, at this stage, it has no Deployments, hence it is Pending. Whenever you modify that code and push the change to GitHub, a new Version of that contract is automatically registered in its Workspace’s Version and Deployment Manager.

Deployments

Every time a new contract is deployed on the Stagenet, its code is checked against all contract Versions. If a match is found, the contract is automatically registered as a Deployment of that Version. As such, repeated deployments of an identical contract are grouped under a shared Version. This structure is how the Version and Deployment Manager organizes smart contracts.

MyContract
├── First Version at GitHub commit sha123abc
│   ├── Deployment at 0xabcde...
│   └── Deployment at 0x12345...
│   └── Deployment at 0xhij789...
├── Second Version at GitHub commit sha456def
│   └── Deployment at 0x67890...
└── Third Version at GitHub commit sha789ghi
    ├── Deployment at 0xfedcb...
    └── Deployment at 0xa1b2c...

If you deploy a new version of a contract on the Stagenet before pushing its code to GitHub, the Stagenet will automatically save that contract as a Deployment of the new Version once the update is pushed. The same applies when you import a repository that contains contracts already deployed on the Stagenet — your Workspaces will appear as Active, not Pending. This is because a Workspace becomes Active as soon as it has at least one registered deployment.

This is simple if link repository to the stagenet and deploy its contracts once. You’ll get a Workspace for each of its contracts. Each Workspace will have one Version (representing the code you just linked/imported) and one Deployment (the deployment you just made).

However, if you decide to deploy one of the contracts again, this will create a second deployment of that contract on your Stagenet. As this deployment is an identical contract (same bytecode) to your initial deployment, they are grouped together as Deployments of the Version.

Contract Versioning

When you update a contract’s code but keep the same contract name, we create a new Version of that contract. Every time you deploy one of those Versions, we create a Deployment of to that specific Version. All Versions and their Deployments are grouped under the same Contract Workspace, which is defined by the contract’s unique name (e.g., MyToken for contract MyToken { ... }).

The Active Deployment

You are able to see all the Version and Deployments of a contract in its Workspace’s History View.