Introducing State Versioning: SemVer, but for Blockchain

[zanicar]

Photo by Ramin Khatibi on Unsplash

SemVer lays the foundation

Semantic Versioning has become dominant and ubiquitous in the world of web 2 and software development in general... but, it is sadly still not a "Silver Bullet" solution for all versioning woes! Allow me to explain...

"SemVer" (the short form of Semantic Versioning) lays an excellent foundation for software version numbers and what they mean, but its focus is exclusively on the API and what these numbers mean in relation to it. It is perfectly suited to the world of web 2 where the vast majority of software revolve around APIs and their consumption... but what to do when something other than the API is the most important aspect of a software system?

The database conundrum

Consider for example the modules or libraries of a database engine where API breaking changes would not be the most significant breaking changes. An API breaking change may require a simple interface update across a number of downstream modules or libraries, whereas a serialization change in the underlying data may require an entire data migration to the new format. This is why you will find a number of prominent software systems not using SemVer.

• Cockroach Labs uses a three-component calendar versioning scheme for CockroachDB;
• Postgres uses an internal format versioning system where the Major version usually indicate a change in the internal format of tables and data files;
• MySQL uses a release series versioning system where the Major and Minor numbers together signify the release series;
• MongoDB uses another type of duo release series versioning system;
• BadgerDB uses a serialization versioning system;

Same problem, but different

Another such example is in the world of blockchain, specifically regarding proof of stake networks that rely on deterministic state machines to bring the network to consensus. In these networks, like their database engine counter parts, APIs are not the most significant breaking changes that can occur; the most significant changes revolve around the state machine...

The following GitHub discussion around versioning of CosmosSDK is very interesting in this regard.

Building on the right foundation

The good news is that we don't have to get rid of the baby with the bathwater; We can simply modify SemVer (as have many software projects) to the particular requirements of our domain. We use the excellent foundation laid by SemVer and apply the principles to our state versioning scheme...

Making semantic versioning more semantic

We define the version number with appropriate semantics: MAJOR.MINOR.PATCH becomes BREAKING.FEATURE.FIX, and we increment the:

1. BREAKING version when any state breaking changes are introduced;
2. FEATURE version when any state-compatible dependency updates or any query API changes, both API-compatible or API-incompatible, are introduced;
3. FIX version when any state-compatible bug fixes are introduced;

Additional labels for release-candidates, pre-release versions and other build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Conclusion

This approach provides for the specific requirements of deterministic blockchain systems while remaining familiar and intuitive. Each version number conveys specific meaning that can be monitored and easily understood by all participants, from node operators running validators to smart contract developers consuming APIs.

Further reading

P.S. for those interested in going further down the rabbit hole here are some interesting/insightful articles:

• Software Versions are Broken, by Eric Elliot
• Semantic Versioning, Go Modules, and Databases, by Francesc Campoy
• Why there would be no Dgraph 2.0: Goodbye Semantic Versioning, by Leyla Galatin

[ghost]

😈🥷👻