Introduction

This page provides an introduction to the policy on how Releases and Version Builds of the Verne Product are created and managed.

Principles Around Building and Releasing Verne

We will support different Clients on a Verne Release to be on different builds of that Release

The policy of issuing a single instance of a Verne Release and then supporting one or two minor versions (i.e. Verne 1.1, Verne 1.2, etc.) will no longer apply.

We will support Clients on different Version Builds of a Verne Release

Clients will be supported on a particular Version Build of a Verne Release. For example, we will support Client A being on Verne Release, Build Version 2.7.4, and Client B being on Verne Release, Build Version 2.8. This provides a far greater degree of granularity of supported Releases, and allow a Client far greater flexibility of when they decide to pursue an upgrade.

We will support Security and/or showstopper fixes for a Verne Release

If a Verne Release is found to have a security or showstopper issue, then we will fix it as a new Version Build within the Release and advise Clients to upgrade to that Version Build accordingly.

In exceptional circumstances, a patch to a Client’s specific Build Version will be issued. This will be discretionary, and subject to agreement by all parties involved. 

We will support the ability for a Client to have patches applied to their Version Build

If circumstances dictate, we will support a patch to a Client’s Version Build. This will allow a Client to get urgent or highly needed fixes without having to commit to a significant upgrade.

Verne Releases and Version Builds

Version Builds

We will align our Version Builds to a numbering convention that identifies the Release and the build. This numbering convention is simple, in that the first number in a Version Build will indicate the name of the Verne Release.

Each build will have it’s own identifying name along with a specific number set. So, any Version Build that starts with 2 will be associated with the Jennings Release, and any number associated with 3 will be associated with the Blanchflower Release. And so on…

We will continue to apply an incremental numbering system within a Verne Release for our Version Builds. As a default, it will be as follows – 3.1.0, 3.2.0, 3.3.0 and so on. We will go further down the tree if needed, to accommodate 3.1.1, 3.1.2, etc.

Verne Release

Support for Clients will be based in terms of named Verne Releases and numbered Version Builds. Because we will now support Clients on their own Version Build (provided the build in use has not been retired) we will typically refer to a Client’s Release as, say, Jennings Release, build 2.8.6.