Introduction
The Intershop offering provides several types of releases. These are presented in this concept.
Our continuous releases enable fast deployment (DevOps) of improvements, new features, and the latest security enhancements and fixes.
This way our customers always have the latest version and can, thus, avoid costly upgrades.
References
Intershop Commerce Management
Release Strategy
Intershop releases versions of Intershop Commerce Management (ICM) in a high cadence to provide customers with bug fixes and new features as quickly as possible. To better understand the impact and compatibility of changes in releases, ICM uses semantic versioning from version 11. Semantic versioning (major, minor, patch) provides information about expected compatibility, see also https://semver.org.
Compatibility Matrix
Semantic version change | Example (forward) | Backward compatibility1 |
|---|---|---|
MAJOR | 1.1.1 to 2.1.0 | incorporates breaking changes2 |
MINOR | 1.1.0 to 1.2.0 | |
PATCH | 1.1.0 to 1.1.1 | |
1) Backward Compatible means that users can update to the latest version without worrying that it will break anything from the previous version.
2) Incorporates breaking changes, it may be necessary to make adjustments to your custom code. Ensure that a new major version has undergone rigorous testing to minimize potential issues.
Release Cycle
Intershop provides two update strategies to suit customer needs:
Monthly Releases: Customers receive monthly updates that deliver new features throughout the lifecycle of the current major release. These updates continue until the end-of-life (EOL) date for the major release.
Bug Fix (Patch) Releases: After a major release reaches its EOL, customers can opt for bug fix releases. These updates include critical security patches and issue resolutions and are available during the support period until the end-of-support (EOS) date. This period also provides a transition period for customers to prepare for the next major release.
Both strategies are offered in parallel, allowing customers to choose between:
Staying current with the latest feature enhancements, or,
Prioritizing stability while receiving the latest security patches.
Continuous Releases for ICM – Monthly Releases
Monthly releases are planned in advance and typically include minor releases characterized by non-breaking, compatible changes such as the introduction of new features and bug fixes. It is advisable to consider monthly releases in the early stages of a project, especially if new features are expected to be introduced. However, improving the API structure (removing deprecated functions or classes) or providing major improvements to external APIs will require at least two major releases (spring / autumn) including breaking and/or incompatible changes per year.
In addition, patch releases will be made available for both the current monthly release and all major releases during their support period.
Current Monthly Release
As soon as a monthly release is introduced, the previous monthly release is considered outdated.
Patches (including critical fixes) are provided on request only for the current monthly release.
Continuous Releases for ICM – Patch Releases
Patch releases may be required between regular monthly releases for urgent security fixes or bug fixes (blockers).
Typically, patches:
Are API-stable,
Do not require migration of customizations,
Do not require database changes,
Can be deployed with zero downtime.
Support Period for Major Releases
After six months, the End of Life (EOL) for a major release is reached and feature development for this release ends. During a subsequent support phase of an additional twelve months, important bug fixes are delivered for this release (patch releases). This supports customers and implementation partners who do not want to update their customizations at such a high cadence but only need the most important updates (bug fixes) on a regular basis. In rare cases, there may also be minor releases due to necessary library updates required for bug fixes.
During these twelve months, it is important to regularly apply the patches provided to ensure secure operation at all times. This additional period is intended to plan and carry out the upgrade to the current or next major release.
Impact of Continuous Releases of ICM
With regard to releases, please note the following:
The customer is accountable for using a current ICM version for the customization project, see also RACI Matrix.
Sometimes changes to customizations may be necessary, for example for deprecated APIs (major version, required changes will be well documented in the release notes).
Acceptance testing is required for each update (major version, minor version) to minimize the potential for issues. This includes:
Core processes
Customizations
Interfaces to 3rd party applications
In addition, automated testing of customizations is highly recommended.
FAQ
Q: Why is the term "Long Term Support" (LTS) being discontinued?
A: The support period for each major release is the same for all releases, making the LTS designation unnecessary.
Q: What terms will be used instead of LTS?
A: We offer a support period for every major release and will focus on the terms "End of Life" (EOL) and "End of Support" (EOS) to provide clearer communication regarding our support policies.
Q: What does End of Life (EOL) mean?
A: End of Life (EOL) indicates the end of feature development for a major release.
Q: What does End of Support (EOS) mean?
A: Until the End of Support (EOS) date, only bug fix releases will be provided. A major release is supported up to the EOS date, which includes a transition period to facilitate the switch to the new major release.
Q: How will this impact existing LTS lines?
A: ICM 7.10.41-LTS and ICM 11.11-LTS will remain unchanged. However, we encourage customers to upgrade to more recent versions.