We’re excited to announce a change in the way we version Corda, and with it, a change in our branching strategy. This change was made to align Corda’s versioning more closely with Enterprise industry norms. In this email, I will explain in brief what has changed and why. For more detail on the rationale behind the versioning change, I recommend Mike Ward’s blog post, which is linked below.

The next version of Corda 

The next version of Corda will be Corda 4.3. In order to align Corda and Corda Enterprise, there will be no Corda 4.2. Instead, Corda 4.3 will be the next major version of Corda released. Corda 4.3 and Corda Enterprise 4.3 will be aligned from a functionality perspective. Note that Corda 4.3 will specify platform version 5.

Please see Mike Ward’s blog post for more detail here.

Development of Corda going forward 

Previously, all development work was done on master. Master will no longer be used, owing to the need to support multiple versions of Corda in flight at any time. Instead, development work will be done on branches that represent the appropriate version. Branches will be named according to the following pattern:

release/os/{major version}.{minor version}

Thus, the branch release/os/4.1 contains the most recently released major version of Corda. The branch release/os/4.3 contains the next major version of Corda, yet to be released.

Where should I make my change? 

If you would like to contribute to Corda, we recommend opening a pull request against the oldest version of Corda to which your work would apply. For instance, if your work would be applicable to Corda 4.1 and Corda 4.3, it would be appropriate to open a pull request for release/os/4.1. That work would then be merged forward from release/os/4.1 to release/os/4.3. If your work is only applicable to Corda 4.3, simply open a pull request against release/os/4.3.

Why was this change made? 

The previous branching structure required changes to be made on master first and then backported to older versions. However, backporting was proving to be complicated and time consuming. In order to streamline development, it was decided that forward merging would be used instead, which required moving away from development based around a master branch.

Thanks,

Jonathan.