Very recently a new item was placed in the footer of Castor: the version number of the software! To keep our users better informed and enhance internal communication between Castor team members, we decided to include the exact version of Castor directly on the website so anyone, no matter their location, knows exactly which version they are looking at. Furthermore, you may notice that it doesn’t follow the traditional semantic versioning style of software management either, but that’s okay! In this blog post, I will explain our reasoning for including the version directly on the website, and why we use a different format.
Keeping you updated!
Have you been anxiously awaiting an update, or excited to expand your study with new features? Now you will know exactly what alterations were made to the system! Keep a lookout at the bottom left hand side of your screen while viewing your study to see if the version number has changed. If it has, you can click on the version number and it will take you to current release notes that outline exactly what is different. Furthermore, you have the opportunity to see minor patches that were released which are updates not presented in any newsletters. This way you can keep track of bug fixes and other minor improvements.
Improving internal processes
With Castor team members based all around the world, we need to carefully build mechanisms to effectively communicate the current condition of our data modelling tool. Clearly labeling software solidifies the communication between developers and testers as they can easily understand which version is available for testing and which feature is accessible for the testers to do their job.
This way, if a bug located in version 2017.1.1 was fixed and a patch for it was released in 2017.1.2, there is no use in the testers looking at 2017.1.1 again. By adding the clear label of the current version, the testers can know with confidence that they are looking at the version the developer deemed as “fixed”. Now, you will get higher quality versions of Castor EDC released more quickly!
Castor versioning
Traditional versioning relies on a MAJOR.MINOR.PATCH approach, leading to the classic numbers you are familiar with such as version 1.2.3 or version 2.6.4. Above you saw our previous version numbers which followed this style, for example 4.7.10. The first number, 1.x.x, symbolizes major changes resulting in incompatible alteration to the API. The second number, x.1.x, refers to minor changes, and the third number, x.x.1, refers to patches or simple bug fixes.
Castor has used this exact same approach that is used to manage software everywhere up until the beginning of 2017. Now, we use a YEAR.MINOR.PATCH approach to better suit our needs and bring more meaning to the numbers.
Since Castor’s first appearance in 2011, it has only reached version 4.x.x. Not many changes we make to the system are major API changes that “break” older versions. Therefore, the minor changes and patches committed to the running version continued to increase drastically while no major changes could “reset” the versioning scheme again.
By replacing the major changes with the current year, we can maintain meaning in our versioning and better communicate the nature of the changes made to the system.
