Version Numbers

Trumpet products are versioned with a 3 digit number (e.g. 2.7.3, 2.18.4).  All versions of the product are released serially (i.e. version 2.7.3 contains all of the changes from 2.7.2, 2.7.1, 2.6.18, 2.6.17, etc…).  New versions are created frequently (often once or twice per week), and each version change consists of a very small amount of changed or additional functionality (i.e. one bug fix or one new feature).

It is not at all unusual for Trumpet to produce 2 or 3 versions of a given product in a single week.

Trumpet also has reporting on which customers have which versions – and whether those installations are in an OK, WARN, or ERROR status level.  We also track support requests (issues) by which version of the software was installed at the time of the request.  This allows us to make quantitative assessment of the risk of a given version of each product.  If a given version is in use at many sites, all of which are OK, and there have been no reported issues for that version, then we can say with confidence that the build is stable and safe to deploy broadly.

Because each version bump incorporates a very small number of changes, it is very, very easy to identify any regression issues that arise.

Release Management

Trumpet has 3 phases that a given software version might go through:

DevRelease	Software is highly unstable.  No testing has been performed.  May contain known and unknown huge glaring bugs and problems. This is not available to download through your software, and should not (and could not) be deployed to any system unless Development is involved
PreRelease	The software is considered stable, and has passed internal QA, but we don’t have exhaustive experience at tons of sites – it may still contain unknown bugs, but regressions are highly unlikely
Production Release	Software has been proven to be robust at a large number of sites – any bugs remaining are small.

 

This means that the latest Production release will always be at the same or less version as the latest PreRelease.  For example, 2.3.7 might be the latest Production release, and 2.3.23 might be the latest PreRelease.  The PreRelease would contain 16 small changes since the Production release was made.

Periodically (usually around every 3 months), a review determines the latest PreRelease that is considered to be ready for Production.  This review consists of looking at how many sites are running the PreRelease, whether there have been any support requests made for versions between the current Production release and the PreRelease that may indicate an issue with the underlying code, and whether sites currently using the PreRelease are in a warning or error state. 

Installers for DevRelease are named ‘DevRelease-ProductName-x.y.z.exe’.  Installers for PreRelease are named ‘PreRelease-ProductName-x.y.z.exe’.  Installers for Production are named without a prefix (‘ProductName-x.y.z.exe’).

Once a PreRelease version has been declared ready for production, a Production release is created with the same version number as the PreRelease (this is the exact same installer – we literally just rename the installer exe).

Once a Production version is identified, we generally bump the second number of the version for the next PreRelease we create.  For example, if a 2.3.16 PreRelease is marked as a Production release, the Production release will be 2.3.16, and the next change we make to the product will be under version 2.4.1.

Risk Management

The reason we have these phases is to minimize the risk of exposing a given problem to a large number of users.  PreReleases tend to roll out gradually to a small handful of sites as we work with firms who actually need functionality, or to those sites who choose to install it pro-actively.  PreRelease and Production releases could be installed by anyone at any time by doing a Help->Check for Updates (or we may send a blast email announcing a new version’s availability).

This approach results in customers being able to install the latest ‘Known Good’ version on a regular basis (3 or 4 times per year), while still enabling customers who need changes or fixes to get rapid updates at extremely low risk.

How risky are PreReleases?

Pre-Release versions are very stable.  If we are fixing a bug or adding new functionality, it is extremely rare that work could cause problems for the useful functionality of earlier versions (we refer to this sort of issue as a ’regression’, and our release management cycle is designed to prevent this sort of issue).  So there is a small chance that a given PreRelease might not completely fix the bug it was intended to fix – or there may be a subtle issue with new functionality that was added - but it is very rare that a given PreRelease would actually break the application in a meaningful way.

If you have an issue or need that the latest PreRelease fixes, it is generally a good idea to update, unless the issue is truly not important to your organization.

PreReleases (if available) can be obtained using the Check for Updates functionality available in all of Trumpet’s applications.

How risky are Production releases?

Production versions are not only very stable, but have had a good number of sites using the version without issue.

We recommend that you install all Production updates as they become available (though it’s perfectly fine to schedule this into your regular maintenance schedule).