Minor Upgrades

Introduction

Goal

Upgrade from the previous minor version to the current minor version.

Background

Minor releases of Hippo CMS are backward compatible. Therefore upgrading from one minor version to the next (e.g. from 13.0 to 13.1) typically always involves the same generic steps. These steps are described on this page.

Which Upgrades are Supported?

Only upgrades to the latest PATCH version within a MINOR version are supported

Our versioning follows the semantic version scheme, so given a version number MAJOR.MINOR.PATCH  we increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards-compatible manner, and
• PATCH version when you make backwards-compatible bug fixes

When upgrading the MINOR version, we can only guarantee 100% backwards-compatibility when you upgrade to the latest available PATCH version of the MINOR version you upgrade to. Without using the latest PATCH version, you might run into backwards incompatibility problems.

Upgrading the MINOR version to MINOR + 2 or more is supported

When upgrading the MINOR version 2 or more higher, this is supported, however, you need to follow all intermediate mandatory upgrade steps as well (if there are mandatory steps).

For example when upgrading from 14.0.0 to 14.2.2, you need to check the upgrade instruction for

1. 14.0.x --> 14.1.y
2. 14.1.y --> 14.2.z

Note that you do not need to deploy after each upgrade step. So the actual deployment of the upgraded project with -Drepo.bootstrap = true (see below) can be done once from 14.0.0 directly to 14.2.2.

Upgrade Steps

Update Hippo Release Pom Version

Each Hippo project created using the Maven archetype defines the Hippo Release Pom as parent in its root pom.xml.

Update the hippo-cms7-release version in your project's root pom.xml. For example when upgrading to 14.2.2:

<parent>
  <groupId>org.onehippo.cms7</groupId>
  <artifactId>hippo-cms7-release</artifactId>
  <version>14.2.2</version>
</parent>

 

Remove Version Properties Overrides

The Hippo Release Pom defines the versions of the many artifacts that make up a release. Individual projects may explicitly override some artifact versions in their root pom.xml, e.g. in order to make use of bug fixes made available since the last release:

    <!--***START temporary override of versions*** -->
    <essentials.version>14.3.0</essentials.version>
    <hippo.hst.version>14.3.1</hippo.hst.version>
    <!-- ***END temporary override of versions*** -->

The next minor release will normally include all bug fixes since the last minor release, making these overrides obsolete.

Remove all version properties overrides from your project's root pom.xml.

Enable Repository Bootstrap on Deployment

Typically a new Hippo release uses the repository bootstrap mechanism to make changes to configuration stored in the repository. To make sure these changes are made the repository bootstrap must be explicitly enabled when deploying the upgraded project.

Enable the repository bootstrap by setting the repo.bootstrap system property to true:

-Drepo.bootstrap=true

Run Groovy Updater Scripts (if any)

A new Hippo release may also use Groovy Updater Scripts to make changes to configuration and/or content stored in the repository.

Run any Groovy Updater Scripts (as described in the upgrade instructions for that release) after deploying the upgraded project.

Check Release Notes for Additional Upgrade Steps specific to the Release

Always check the release notes and upgrade instructions for the new Hippo release for any additional steps required for that specific release.