This topic describes the Hologres product lifecycle policy, version discontinuation policy, version numbering scheme, version relationships, and important lifecycle events.
Background information
Product updates and phase-outs are common for infrastructure software. Hologres is developing rapidly. New versions provide richer, more powerful, and easier-to-use features. Older versions gradually become outdated. Their features may no longer meet your evolving business needs. Older versions face increasing challenges in application stability, usability, and system compatibility. New versions will eventually replace them. Managing the product lifecycle and introducing new versions in a structured manner helps you keep your technology current and use the product more effectively. For more information about the features of each Hologres version, see Release notes. Hologres considers factors such as migration, the internal cost and stability associated with validating new versions, and long-term IT planning. To provide better enterprise-level services and offer insight into future product evolution, Hologres created a lifecycle management system. This system defines the product lifecycle and discontinuation policies to help you understand the rules and prepare in advance.
Product lifecycle policy
The product lifecycle policy describes the process of a Hologres version from its official release to its end of service. The following figure shows the lifecycle of a Hologres version.
Milestone | Full name | Definition | Time point | Description |
GA | General Availability | Official release | Month T | The version is officially released for use in production environments. |
EOS | End of Service | Service termination | Month T + 2 years | New versions, including patch versions, are no longer released. Note During the EOS phase, services such as Q&A, problem resolution, and Service-Level Agreement (SLA) compensation are discontinued. |
Each phase will not start earlier than the committed time. You will be notified through official channels at least three months in advance.
If a major defect that could cause significant loss, such as a security issue or data inaccuracy, is found in a version, Hologres reserves the right to perform an emergency upgrade. The upgrade will be to a compatible fix version within the same major version.
For an instance at the End of Service (EOS) stage, if Hologres Operations and Maintenance (O&M) determines that the instance poses a potential stability risk to you or the entire cluster, Hologres O&M has the right to upgrade the instance during an O&M window. The instance is upgraded to a stable version that is still in its GA period.
You can view the current and target upgrade versions of an instance on the Instance Details page in the Hologres console. For more information, see Common errors for failed upgrade preparations.
Version numbers and their meanings
Hologres uses a two-part numbering scheme to specify product release versions. The format is Major.Minor. The meanings of Major and Minor are as follows.
Major: Indicates fundamental changes and additions to Hologres features. The major version number is incremented based on the size and scale of the changes in each release.
Minor: Indicates quality improvements and fixes to existing features. The minor version number is incremented when a significant number of quality improvements are added to a release.
Version | Meaning | Hologres upgrade policy | Example |
Major version | New features and bug fixes. | Increments the Major part. | Version |
Minor version | Compatibility improvements and bug fixes. | Increments the Minor part. | Version |
Version correspondence and important lifecycle dates
The following table lists the GA and EOS dates for each Hologres version.
Hologres major version | GA | EOS |
0.7 | 2020-04 | 2022-04 |
0.8 | 2020-10 | 2022-10 |
0.9 | 2021-01 | 2023-01 |
0.10 | 2021-05 | 2023-05 |
1.1 | 2021-10 | 2023-10 |
1.3 | 2022-07 | 2024-07 |
2.0 | 2023-04 | 2025-04 |
2.1 | 2023-10 | 2025-10 |
2.2 | 2024-04 | 2026-04 |
3.0 | 2024-07 | To be determined |
3.1 | 2025-06 | To be determined |
3.2 | 2025-06 | To be determined |
4.0 | 2025-09 | To be determined |
Service commitments and suggestions
Compatibility
Alibaba Cloud Hologres does not guarantee compatibility between major versions. We make every effort to maintain the compatibility of program logic, SQL syntax, and interfaces between different major versions. We will inform you of any potential incompatibilities through documentation or after-sales service.
Alibaba Cloud Hologres guarantees compatibility between minor versions within the same major version. This compatibility covers SQL syntax, interfaces, and the engine framework. It does not cover program business logic or data processing. Therefore, we recommend that you upgrade to the latest minor version within the same major version to ensure compatibility.
Bugs
If you are not using the latest version, you can upgrade to a newer version, either a major or minor version, to fix bugs. This approach is based on our compatibility commitment. For example, if your job uses version 1.1.33 and the latest version is 1.3.40, you can upgrade the engine to version 1.3.40 or a later version to fix the bugs.
Feature releases and bug fixes are announced in documents such as the Release notes.
Related services and notifications
Based on the lifecycle policy and version information, we will:
Plan the lifecycle for each Hologres version and communicate this plan to you during product discussions and service interactions.
Notify the primary Alibaba Cloud account at least three months before a key lifecycle milestone. Notifications are sent through website announcements, announcements in the product documentation, internal messages, emails, or text messages. To receive these notifications, ensure that the account is subscribed to product update messages in the Message Center.
Help you assess job-related risks and discuss solutions before a version reaches its end of service.
After a version reaches its end of service, Hologres O&M will proactively upgrade the instance if necessary to maintain stability. The instance will be upgraded to a stable version that is still within its service period.