Corda 3.1

Katelyn Baker in Corda

Hey everybody. Kat here… Release Manager for Corda 3.1 (and developer of the Corda serialization framework in my “spare” time)

Delivering the Corda platform, seeing it go from a concept to open, but unreleased, alpha code, through a beta process, through to its first major releases over the past few years has been a truly exciting time for the R3 ecosystem and the open source community that’s formed around Corda. As Corda matures as a platform that developers and businesses rely on it will continue to evolve and grow as the stable released versions are actively maintained.

Part of that process, as with all software projects, is bundling fixes into minor releases that provide a well-tested set of bug fixes. Thus begins the ongoing process of maintaining Corda version three with its first minor release. The promises made for the 3.0 release remain unbroken: API and Wire Stability are intact and whilst we recommend upgrading to 3.1 to take advantage of the bugs fixed, if you aren’t experiencing any of them, it will be a transparent change.

The primary driver for 3.1 was delivering a fix for the “unknown constant pool tag” issue that was generated by the serialization framework when used by CorDapps deploying a REST API using Spring Boot. The underlying issue was with a third party library Corda depends on for scanning the classpath, the Fast Classpath Scanner (https://github.com/lukehutch/fast-classpath-scanner). This is an issue that was fixed some time ago by the maintainer of the package. Unfortunately, 3.0 depended on a version without that fix. This has been corrected for 3.1 and additional internal testing implemented. As ever, we’re grateful to the community for finding these issues and working with us to reproduce them and produce a fix.

The other notable change is with our versioning scheme. Corda 3.0 shipped versioned as “corda-3.0”. This changed the established scheme used in versions 1 and 2 where they were simply “1.0.0” and “2.0.0”, respectively. The change was made with the desire to allow developers to more easily distinguish between the base Corda open source platform and any future commercial distributions that may ship in the future. This would allow you easily to flag in your build systems exactly which dependency was being used.

Unfortunately, the law of unintended consequences struck. We failed to take into account how this would impact third-party tools, such as search on Maven Central and thus for 3.1 and future releases we will be inverting the ordering such that the version moniker is appended rather than prepended to the version number. I would be remiss if I didn’t note that a number of colleagues did point there would be issues with making the original change. Mea culpa! (Let’s hope by the time we release 3.2 everyone will have collectively forgotten this was ever “a thing”…!)

Additionally, we’ve removed the patch number from the version string as, ultimately, we don’t intend for Corda to have patches released for it. Bug fixes will be made available as general releases that will either bump the minor version number where no new API or major feature is added or, when they are, bump the major version. These releases will be done on an as-needed basis. 3.1 is a great example of that: it wraps a number of smaller fixes but the impetus was to correct a problem impacting a lot of people and decisions around future releases will be done in the same fashion. When it’s needed, it’ll be done.