Releases and Software Versions

The average end user doesn't care about software versions, but they do care how fast they get bugs fixed and new features provided, and for us developers, this means releases. So, lets talk about releases!

TL;DR; To cut a long story short, our next release after 1.8 will be 2.0.0 and from then we will use MAJOR.MINOR.PATCH version numbers.

With the recent release of 1.8.5 the Xibo project can count 23 releases on GitHub and 46 releases on our previous system. We've always considered the indicator of a major release that contains substantial new features to be the middle release number, the "SERIES" in the following, STEP.SERIES.MINOR. This means 8 series releases since 2009, or a little over a year between them.

In reality we often put small new features into the MINOR release number and a MINOR release typically arrives every 2-3 months. There are always a set of bugs fixed in these type of releases too - almost always with over 10 items and sometimes as high as 100 items resolved. Why am I writing about this? Well, there are some problems with it that we want to try and address. These problems, in no particular order, are:

• MINOR releases contain features and bug fixes
• MINOR releases can be simple to deploy, but can also be complex, depending on their content
• MINOR releases are hard to do and take a long time
• Therefore, bugs are fixed quickly but released slowly
• SERIES releases are HUGE containing hundreds of issues and features
• SERIES releases happen very infrequently and represent big changes in functionality
• It is hard to know what you're going to get in a release
• Windows Player updates are joined to the Xibo CMS release, which often means you need the CMS from release X and the Player from release Y
• Xibo is 14 years old and still on version 1, STEP releases never happen

These factors mean that end users are reluctant to upgrade to a MINOR release, as they might get new features or a breaking change, but equally they wait far too long for a SERIES release containing the feature they want. In other words, updates are perceived as risky or inconvenient and we understand why!

xkcd.com

What to do?

We want to improve on this for all future releases after the current SERIES by changing the way we do things. Our next release after 1.8 will be 2.0.0 and from then we will use MAJOR.MINOR.PATCH version numbers. This will work as follows:

• MAJOR: Significant new features which change the way the product works. These will require user training and Player upgrades. Relevant examples from 2.0.0 are the Playlists and Interactive Signage functionality.
• MINOR: Small new features which compliment existing functionality, such as new Widgets, additional fields, permissions, dashboards. These will not require Player updates unless the new feature is needed or significantly change existing functionality.
• PATCH: Only bug fixes, no changes to functionality, no Player updates.

We will also separate the Player and CMS releases so that the next Player release will be v2. This means that if you are running CMS 2.0.0, 2.0.1, 2.1.0, 2.x.x, any v2 Player will be compatible, and the latest v2 Player will support all features. If you are running CMS 3.x.x you will need the latest v3 Player, etc.

To make this change in numbering clear, we will skip 1.9.x and go directly to 2.x.x. All planned features for our 1.9 release will be included in 2.0.0.

Commercial Player licensing

Xibo for Android and Xibo for webOS Player licensing will remain unchanged for existing licence holders of 1.6, 1.7 or 1.8 licences - you may continue to use your version of the software in perpuity as before.

The next release of these Players to contain the significant feature changes of 2.0.0 will be called v2, and upgrade licences can then be purchased to go from one major version to the next.

From then onward those licences are valid for the whole of v2 and the next upgrades charged at v3, v4, v5, etc.

To conclude

We've really thought about how we manage development and the release cycle here at Xibo HQ. We hope that the above steps will move us in the right direction - towards a more stable product, which gets fixed fast and improved gradually, with well defined releases.