Versioning and releasing your virtual appliance

[author:alex]

Software versioning is an art

In the world of distributing virtual appliances, same as you would with software, sticking to a well defined versioning system is worth the time it takes to implement.

An approach

One common approach is Semver, drafted by my old boss at GitHub: Tom Preston-Werner.

I like this approach, but I find it applies mostly to software projects with very short release cycles. In the Enterprise world, you’d be lucky to ship more than one update per month. There are various reasons for this, sometimes because you’re too busy supporting your customers.

What others are doing

Ironically, GitHub uses a different and odd versioning scheme for their Enterprise appliance (ex: 11.10.320). I know the secret behind this version scheme, but I can’t tell you :P

The only thing which ever changes is the number after the last dot. That’s fine, but you would think the appliance never received a major update.

I’m somewhat partial to Chrome and Firefox’s approach: Single-digit version numbers with minor patch numbers.

First things first

Let’s define a few things:

• Release: This is either a virtual appliance or an update package released to your customers.
• Install: A brand new installation which may or may not use a completely different OS, installation script, and/or software packages.
• Provision: A customized virtual appliance, originally cloned from an Install.
• Major: The first number in a version scheme: ex: 1 in v1.0
• Minor: The second number after the dot in a version scheme: ex 0 in v1.0

We realize the need to perform a new Install is quite low. Once you have a good base OS installation, it’s unlikely you would need another one unless you plan to make Major changes to it, such as altering the partition scheme, or updating the OS version (ex: from Debian 7.2 to Debian 7.3).

The most common task is a Provision task. Since we have no way of knowing the changes taking place, we’ll assume the changes are Minor.

A simpler approach

We’ve taken Semver and chopped off the last decimal+digit. This leaves us with only a Major and Minor version number.

Example: myappliance-v1.0

Here’s how it works:

1. A new Install increases the Major version number
2. A new Provision task increases the Minor version number
3. A new Release increases your bank balance

Handling releases

In my opinion, it doesn’t matter if the Minor versions between releases are not sequential. You can get up to version n.328 after n.320 and nobody will care, as long as the number is higher than the previous release.

Releases are important and need to be broadcast, because it shows customers you’re still working on and maintaining your product. This information is valid for potential customers as well.

What’s in a release?

A release should contain four very important things:

• A ChangeLog describing what was changed/added/removed from the previous version, and the type of changes: security, bug, feature, etc.
• An update package, for people who simply want to update their existing virtual appliance.
• A new virtual appliance, for people who want to completely start over. This applies to those who’d rather migrate their data to a new appliance, rather than update an existing one.
• Instructions on how to apply the update. Often overlooked, if you don’t clearly explain how to do it, it might never get done.

How we can help

With Jidoteki, we built-in the ability to handle this type of versioning for you.

When you perform a new installation, we take the name of the appliance, and append something like “-v1.0”.

1. We increase its Major number by 1 (starting at 0 if it’s your first install).
2. We then increase the Minor each time you provision the appliance.
3. After 5 provision tasks, your appliance will be: v1.5
4. When you finally decide to Release an appliance or update, we put stars next to it and ensure you don’t accidentally delete it.

Of course, Jidoteki’s versioning is completely optional. You can choose to skip it and use your own versioning scheme if you prefer.

We’re planning on soft-launching Jidoteki in the next few weeks, so if you didn’t already signup for early access, DO IT NOW! We’ll provide early customers with discounted usage once we officially launch.

The signup form is at the bottom of this page.

As usual, feel free to contact me on Twitter or email if you need help to sell your SaaS, behind the firewall.