All You Need to Know About Vidispine’s Release Schedule
This post explains the version numbering scheme of Vidispine releases. We aim to release new major versions every 24-36 months, with a new minor release coming every 3-6 months. In-between we release maintenance and pre-release versions.
In this post, we will describe the Vidispine Server release lifecycle, and the different parts of a Vidispine Server version number, and how different components with different versions are related.
The Version number
There are four different parts of the version number. Let’s take the version number 4.5.1-pre16055 as an example.
Major and minor version number
In the version number above, “4” is the major version, and “5” is the minor version. A minor version (e.g. 4.5) has a base lifecycle period of 15 months: 9 months in proactive maintenance mode followed by 6 months in reactive support mode. When a new major version is released (e.g 5.0), the maintenance period for the preceding minor version will be extended with 6 months (followed by 6 months support mode), offering customers a 12-month upgrade window.
A change in major version indicates a structural change in license or deployment model. We release new major versions approximately every 24-36 month. Old major versions are supported (with maintenance releases) for 12 months after new major version is released.
New minor versions indicate new features. New minor versions are released approximately every 3-6 month. In general, when upgrading from an old minor version, the database should be migrated (vs-admin db migrate) and the Solr indexes should be re-indexed. However, always read the release notes and the update notes. New features are scheduled for coming minor versions.
The Maintenance version number
I 4.5.1, “1” is the maintenance version number. Maintenance releases contains bug fixes to the minor version. When upgrading between maintenance versions, a database migration is typically not needed, but it is always good to read the release notes. Note that for the first release of every minor release, there is no maintenance number. So you can think of 4.5 as “4.5.0”.
Within the same major version, max 3 minor versions will be in maintenance mode simultaneously. Minor versions are released on a three month schedule. When a minor version enters support mode (EOM), hotfixes can be provided on request. The ability to request hotfixes ends when the minor version reaches EOS, whereafter only limited technical support will be provided.
The Build number
Sometimes we deliver pre-releases. The intention of these builds is for users to verify bug fixes or new functionality before they are released. The pre-releases are not meant to be deployed in production. A pre-release is identified by the suffix “pre” and a build number.
Are fixes in version X included in version Y?
Fixes are applied to minor versions. That is,
- minor version x.y.z contains all fixes in x.y.w for z > w. (4.5.2 contains all fixes in 4.5.1, which includes all fixes in 4.5.)
For pre-releases, newer builds contains all fixes for previous builds and previous maintenance releases. That is,
- version x.y.z-preU contains all fixes in x.y.(z-1), and all fixes in x.y.z.preV for U > V. (4.5.2-pre17000 contains all fixes in 4.5.1 and 4.5.2-pre-16578. 4.5.2-pre17000 does not contain all fixes in official maintenance release 4.5.2.)
Between minor releases the story is different. You cannot check solely on the version number. Bug fixes are imported from previous minor releases when a newer minor version is released. Example:
- Version 4.3.1 is released March 17
- Version 4.4.3 is released March 29
- Version 4.3.2 is released April 12 with a bug fix
- Here, version 4.4.3 does not include the bug fix in 4.3.2.
- Version 4.4.3 is released April 20. It will include the bug fix from 4.3.2.
Vidispine will try to release maintenance versions for the different minor versions at the same time, to minimize any confusion. The Vidispine Support Portal contains the latest Vidispine EOM and EOS Schedule (login needed).
Can I mix components with different versions?
Different components have different inter-dependencies. We recommend that you run the same versions across the board. If not, here are some rules of thumb:
- The Solr package should run with the corresponding Vidispine server package.
- The Vidispine Server Agent (VSA) package should match the Vidispine server package, at least on the minor level. (You can probably run VSA-4.4.2 with Vidispine-4.4.5, but check with us.)
- The Transcoder package should match the VSA package, or be newer than the VSA package.
- The Transcoder package should match the Vidispine server package, or be newer than the Vidispine server package. Running transcoder-4.5 on vidispine-server-4.2 is fine.
However, in the release testing of Vidispine, only the same version are checked.