Corda release versioning changes

With the next major release of Corda, we’re revising our versioning to more closely align to industry norms for Enterprise software.

Internally, we adopt the convention of platforms like Android or Chrome, which have frequently incrementing version numbers. These reflect the rapid progress the platforms are making in capability and are seemed well suited to Corda’s fast-moving improvements. We call this Corda’s “platform version”. As Corda’s original users were developers, we also used this number to name Corda releases themselves. Corda’s version numbers match the platform version they embody. As such, Corda’s own versioning has been developer-centric with a version incrementing when a new API was made available to developers. This would indicate to developers if the API their CorDapp may have depended on was available in the platform it was deployed to.

As Corda moves deeper into mission-critical environments, Corda’s version number is visible to a larger community. Given how much meaning a version number can hold to different stakeholder groups, it’s time to revisit the policy.

The perspective of large enterprise organizations deploying software is this: a version number indicates how disruptive a given release may be to their tested configuration. Corda’s frequently incrementing version numbers triggered the policies of these organizations to require retesting of their configuration which is an expensive and lengthy process. Often, the release would not deem such a re-test, but tying the Corda version number to underlying (API) platform version lacked the fidelity to indicate this. So this has led to some challenges:

– Major version increments were made whenever a new API was added, even if it did not require any network-level upgrades. This didn’t provide information on the impact of a release to operators of Corda.

– Corda versions jumped even when the underlying change was trivial (e.g. as happened from Corda 1.0 to Corda 2.0).

– We did not attempt to align version numbers for open source and Enterprise. It was difficult to ascertain which Enterprise release contained the same functionality as the open-source release.

As such we have decided to revise our numbering scheme. Our aim is to align with norms for IT operations. Additionally, we aim to give more information on the impact of a release for both developers and IT operations. The new numbering policy has a standard format:

– Major version increments (integer) of Corda are now reserved for cases where an entire network would need to upgrade before all the functionality of a release could be utilized. This includes wire protocol changes or capabilities where network consensus is impacted.

– The first decimal is a simple incrementing release indicating a set of new capabilities that can be adopted unilaterally by node operators or application developers without requiring the whole network to have upgraded.

– We will align these release numbers for Corda and Corda Enterprise. Versions that provide the same functionality will, wherever possible, have the same version number. This means we will sometimes ‘skip’ a minor version if required, as will shortly happen (see below).

– When a new API is added to Corda, we continue to signal this to app developers this through an increase in the “platform version”. The platform version will be indicated in release notes and continue to move as sequential whole numbers. It will no longer move in lockstep with the Corda release number.

The practical impact will be that the major (integer) version of Corda will be incremented less frequently than before, and OS and Ent versions will be more closely aligned. We anticipate this will give far better information to both developers and other IT professionals and give more clarity on the impact of a release to users.

How does this affect you?

We’ll be making some changes in our upcoming releases to align with this change.

– The next major release of Corda will be 4.3 (we’ll have more on this soon in a separate blog post). Internally we have referred to this as Corda 5. The significance of the release hasn’t changed. The meta-data we will indicate includes the platform version 5 (a detail of importance only to developers).

– We will align Corda and Corda Enterprise starting with the next release. The next release will skip Corda 4.2 so that Corda 4.3 and Corda Enterprise 4.3 are aligned from a functionality perspective.

We will not be revising past release numbers to align with the new versioning. Luckily, turns out that had we done such a re-alignment we’d actually be at the same number! Releases through Corda 4 would have necessitated whole number increments as they were either consensus or wire protocol breaking changes. For example, reference States correctly necessitated a bump from Corda 3.x to Corda 4.0.

We think this simple change will lead to greater clarity in what’s in a release and its impact on all stakeholders.

---

Corda release versioning changes was originally published in Corda on Medium, where people are continuing the conversation by highlighting and responding to this story.