New TurnKey appliance versioning regime

Updated Appliance Versioning

Users who have been using TurnKey for a while, may have noticed that the release cycle of TurnKey appliances has changed in more recent times. Since version 14.2, we quietly implemented a new versioning regime which allows for appliances to released individually, i.e. be on different versions. This allows us to update specific appliances as needed, rather than needing to wait and do them all in a batch. I've been meaning to explicitly share this info for a while now, so here we go...!

Whilst implemented some time ago, this new versioning regime wasn't really used until we hit v15.x, possibly most noticeably with some of the higher profile updates we've done, such as Drupal security updates (e.g. this one), and the dreaded MySQL/MariaDB issue that hit. It would have been obvious for long term users who have been paying attention when I did my most recent general update post! (Please note that I'm overdue for another of those announcements too. So watch this space!)

How does it work now?

So we have re-engineered our build chain to support the appliances being at different versions. I had initially hoped to just add an additional 'point' (e.g. v15.0.1, v15.0.2, etc). However, once we investigated deeper, it became apparent that we have a lot of dependency on the assumption of a 2 part version scheme. So to minimise the workload and the chance of regressions, we decided to keep the existing version scheme. I.e. 'MAJOR_VERSION [dot] MINOR_VERSION'. However, each appliance can now be updated independently of the rest of the library.

When each appliance is updated, we simply increment the MINOR_VERSION number by one. That does mean that the relevance to major changes across the whole library (previously noted in the Core changelog) don't apply to a specific version across all appliances, but we aim to ensure that these changes are reflected in the individual appliance changelogs. The last few set of changes for each individual appliance can be viewed from the "changelogs" link on each appliance page (e.g. the Drupal8 appliance changes. And/or the full changelog can be viewed by following the appliance page "Source code" link and viewing the changelog file (within GitHub - e.g. Drupal8 full changelog).

The Upside of Changing

One of the biggest complaints we've had over the years, is how long it takes for buggy appliances to be fixed. This complaint is especially valid when you consider that often the bugs are found relatively quickly. Sometimes they are even fixed quite quickly too. However due to our previous release schedule (including the requirement of all appliances being at the same version), doing individual bugfix releases has not really been an option.

We have always had a policy of rebuilding appliances which have "show stopper" bugs. E.g. the namesake webapp doesn't work. We have had a similar policy when it comes to critical security bugs. However due to our previous versioning regime (which relies on all the appliances being the same version), the only re-release options we've had have been either re-release the appliance under the exact same version. Or re-release the whole library!

Whilst that sort of solves the really serious issues, it is a bit dirty. It makes it really hard for a user to know whether they have the version with the bug or not. On face value they appear identical. It's only through digging through the mirror and/or hash files (or installing it and checking) that you can confirm whether you have the good or the broken build.

Furthermore, it also means that some buggy appliances (albeit not totally broken), remained available for extended periods of time. This is especially frustrating for community members who may have provided the fix, but still couldn't download the fixed appliance in a timely manner.

Other Improvements

Many users are likely aware of the Confconsole Plugin system that we developed way back when we released v14.2 Core. We've been slowly and quietly adding a few appliance specific plugins to some appliances to support additional functionality. We have ideas for more, but if you have specific suggestions, we'd love to hear!

We have also been slowly but surely updating lots of our appliance build code to automatically pull in the latest upstream version of software. Mostly that is of value to new users, or users who wish to spin up a new instance. For those appliances that auto seek the latest version, it means that often all we need to do to update that specific appliance is to rebuild it (and obviously give it a quick test too to make sure it all works).

Even Better If...

The turnaround time for updates is still longer than we'd like. Plus we still need to manually test each appliance (which also adds to the time it takes), but we believe that it's a major step in the right direction. So it still won't be instant rebuild with auto regression testing (what we'd really like to have). Also as there is still some overhead to each rebuild, we still need to batch together updates as much as we can. But we aim to at least do important rebuilds (e.g. bugfixes and/or security updates) at least every month or 2.

Which appliances get updated and rebuilt will somewhat be up to you. We aim to be as responsive to user input as possible, so if you find a bug, or can see an obvious improvement, please let us know ASAP.

We also warmly welcome contributions to all the appliance build code so any updates that users such as you provide, we'll aim to prioritise. As per usual, please feel free to post bugs and feature requests on our Issue Tracker and/or post in the