Backward Compatibility

Introduction

Goal

Understand the difference between backward compatible and backward incompatible distributions and which Bloomreach Cloud deployment strategy can be used with each.

Background

Bloomreach Cloud supports two deployment strategies: rolling updates and blue-green deployment. The rolling updates strategy can only be used when subsequent distributions of your implementation project are backward compatible. The blue-green deployment strategy also supports backward incompatible distributions.

This page explains how to determine if a distribution is backward compatible or not.

What is Backward Compatibility?

In the context of deployment to Bloomreach Cloud, backward compatibility is defined as follows:

A distribution is backward compatible if it can be deployed in an existing environment without the need to update the repository instance running in that environment.

Backward Compatibility of Bloomreach Experience Manager Product Releases

A distribution can include an upgrade to a newer Bloomreach Experience Manager version. Bloomreach Experience Manager product releases are versioned using the semantic versioning scheme.

• A major Bloomreach Experience Manager release can (and most likely will) introduce backward incompatible changes.
  For example: Bloomreach Experience Manager 13.0.0 can introduce changes that are backward incompatible with all previous releases.
• A minor or maintenance Bloomreach Experience Manager release is guaranteed to be backward compatible with all previous releases with the same major version.
  For example: Bloomreach Experience Manager 12.4.0 is backward compatible with 12.3.x, 12.2.x, 12.1.x, 12.0.x.

Backward Compatibility of Bloomreach Experience Manager Implementation Projects

A Bloomreach Experience Manager implementation project can introduce backward incompatible changes.

The most common area where backward incompatible changes occur is a project's document types. Which changes to document types are backward compatible and which are backward incompatible is explained in Update Document Templates. In short:

• Only adding a new document type and adding a new non-required field to an existing document type are backward compatible.
• All other changes to document types are considered backward incompatible.

In case of custom project features that store data in the content repository, the same prinicipal applies to any custom JCR namespaces defined by the project. Which namespace changes are backward compatible and which are backward incompatible is explained in Namespace Migration. In short:

• Backward-compatible: those changes that can be applied without worrying about existing nodes in the repository that use the namespace's node type definitions.
• Backward-incompatible: those changes that might lead to problems with such existing nodes.