Ingres DBMS Versioning Policy
Actian Corporation uses a v.r.m versioning scheme to name its Database releases. Associated with the Actian Corporation releases is:
- Product Support Lifecycle Dates at http://www.actian.com/support-services/support#lifecycle
- Product Support Policies at http://www.actian.com/support-services/support#policy.
The Product Support Lifecycle refers to the change in the highest level identifier only. So, a major release is supported for 5 years from the time that it goes GA with each subsequent minor release and service packs as part of the lifecycle.
We always recommend that all users run the latest available minor release for whatever major version is in use. The community considers not upgrading to be riskier than upgrading.
|v = First part||9.x.x||Major release identifier – contains major feature changes|
|r = Second part||9.2.x||Minor release identifier - contains minor feature changes + maintenance|
|m = Third part||9.2.1||Service Pack identifier – contains only maintenance|
Major releases occur only when introducing important functionality with possible destabilizing side effects and occur roughly once every 2 years, as required. A major release is numbered by increasing the first part of the version number, e.g. 2.x.x to 9.x.x. Major releases usually change the internal format of system catalogs and data files. These changes are often complex, so we don't maintain backward compatibility for data files. An unloaddb or upgradedb of the database is required for major upgrades.
Minor releases are numbered by increasing the second part of the version number and occur roughly once every year, e.g. 9.1.x to 9.2.x. A minor release may include some minor feature changes and fixes for all resolved problems. All users should upgrade to the most recent minor release as soon as possible as prior minor releases will be stabilized and all new maintenance will be applied to the latest minor release only. While upgrades have some risk, Actian minor releases implement only minor features that have minimal impact on the code line and which can only be executed when the new feature is used.
Service Packs are numbered by increasing the third part of the version number, e.g. 9.2.0 to 9.2.1. A service pack only includes resolved problems; no new features. All users should upgrade to the most recent service pack once available as all new patches are only released on the code line associated with that service pack. A service pack is nothing more than the current cumulative patch that has gone through a complete QA cycle. An upgradedb is required to implement a service pack because the internal version number is required to be changed in the system catalog but all existing data files remain the same. In between service packs cumulative patches are released to address core problems as resolved.
Prior to any new major release, Actian Corporation will release one last minor release (9.2.x) which will be the final minor release. This release is called the ‘Terminal Release’ and is the final all platform release in the product lifecycle. In some unique cases a terminal release may not be identical for all platforms depending on how the platform has progressed through the lifecycle.
Following the ‘Terminal Release’, Actian Corporation may have limited platform releases targeted at new functionality for the market place. These releases will follow the same product lifecycle as above. One exception is that a customer running on a platform not targeted in these interim releases will not be required to move to these releases; they can remain on the defined ‘Terminal Release’.