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 different parts of a Vidispine 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.
The Major version number
In the version number above, “4” is the major version. A change in major version indicates a structural change in license or deployment model. New major version occur approximately every 24-36 month. Old major versions are supported (with maintenance releases) for 12 month after new major version is released.
The Minor version number
“5” is the minor version. New minor versions indicate new features. New minor versions are released approximately every 3-6 month. In general, when upgrading from an old minor versions, 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”.
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.
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.