Document Tree
Document Properties
Kbid
31M026
Last Modified
09-Dec-2024
Added to KB
06-Oct-2023
Public Access
Everyone
Status
Online
Doc Type
Concepts
Product
  • ICM 11
  • IOM 4.0
  • IOM 4.1
  • IOM 4.2
  • IOM 4.3
  • IOM 4.4
  • IOM 4.5
  • IOM 4.6
  • ICM 12
Concept - Continuous Releases (valid to 11.11)

Introduction

The Intershop offering provides several types of releases. These are presented in this concept.

Our continuous releases enable a fast deployment (DevOps) of improvements, new features, and latest security enhancements/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
(moving forward)

MAJOR

1.1.1 to 2.1.0

incorporates breaking changes2

MINOR

1.1.0 to 1.2.0

(tick)

PATCH

1.1.0 to 1.1.1

(tick)

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 offers two main types of release cycles: monthly releases and long-term support (LTS) releases.

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, there are patch releases that apply to both the current monthly release and the long-term support (LTS) releases.

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.

Long Term Support (LTS) Releases for ICM

Intershop offers long-term support (LTS) releases for 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.

Long-term support releases are released every six months and are provided with patch releases for at least twelve months. In rare cases, there may also be minor releases due to necessary library updates.
During these twelve months, it is important to regularly update to the patches provided to ensure secure operation at all times.
The included six-month transition period is used to plan and perform the upgrade to the LTS line of the next major release.

No new features are provided in long-term support releases.

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.

Intershop Order Management

Update Principles

IOM release management focuses on the "keep current" approach, i.e. the latest release is preferred whenever possible.

This allows our customers to: 

  • Use the latest IOM features

  • Be prepared for upcoming unplanned security patches, if necessary

  • Use the latest versions of 3rd party libraries

In return, Intershop ensures that:

  • APIs are kept stable whenever possible

  • Migration efforts are reduced to a minimum

Release Types

Starting from IOM 4, IOM releases will follow the semantic versioning approach. The following release types are available:

Frequency

API Changes

Transition Period

Major Release

1-2 times / year

Significant breaking changes

12 weeks

Minor Release

4-8 times / year

Compatible changes (new functionality)

4 weeks

Patch Release

on demand

Compatible changes (bugfixes)

-

There is no fixed time frame for these release types.

Patches, formerly known as hotfix, are only provided for supported versions on demand. There is no obligation to upgrade to patch versions, the customer is accountable for any risk. An example for significant breaking changes: removal of previously marked deprecations.

Transition Period

The transition period describes a timespan after the introduction of a new release during which patches for the previous release are still provided. If the new release is a major version, the transition period lasts 12 weeks. If it is a minor release, it lasts for 4 weeks. After the transition period, no further patches will be provided for the respective previous minor or major version. Latest at this point, Intershop recommends updating to a new version.

The following graphics show two examples, both for the transition period for a major release as well as for a minor release:

The dates and time periods used in the examples are for illustrative purposes only. There are no fixed times for releases. 

Example A

After the introduction of the 5.0 major release, there is a 12-week transition period during which 4.x patches are still provided:

Example B

After each minor release, there is a 4-week transition period during which patches for the previous minor version are still provided:

Supported Versions

Intershop considers all major/minor IOM versions as supported, as long as no new major or minor version has been announced. There is a transition period of 4 weeks for minor and 12 weeks for major versions, see Release Types.

Customers or partners running unsupported versions will be supported with issue analyzing. However, this applies only to the current current and x-1 major release.

Patches are available only for supported versions.

Disclaimer
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.
The Intershop Knowledge Portal uses only technically necessary cookies. We do not track visitors or have visitors tracked by 3rd parties. Please find further information on privacy in the Intershop Privacy Policy and Legal Notice.
Home
Knowledge Base
Product Releases
Log on to continue
This Knowledge Base document is reserved for registered customers.
Log on with your Intershop Entra ID to continue.
Write an email to supportadmin@intershop.de if you experience login issues,
or if you want to register as customer.