Release & Support Lifecycle documentation for the dotCMS Content Management System

This document describes guidelines and practices for the dotCMS release cycle and to define how previously released versions of dotCMS will be supported and patched until they reach EOL (End of Life). dotCMS is committed to supporting Enterprise customers throughout the lifecycle of their dotCMS deployments. The guidelines in this document lay out the responsibilities of dotCMS in supporting released versions and the responsibilities and expectations of dotCMS customers in requesting support.

The dotCMS Release Lifecycle

The challenge at any software company is that it is only possible to support, test, and maintain a limited number of codebases and platforms at any one time. The more codebases a software company has to maintain, the more difficult it is to provide effective product support. In addition, support issues may arise that are core to the codebase and require R&D attention.

It is very important for customers to upgrade to newer, fully supported releases periodically.

  • Fully supported versions of dotCMS have fixes for many issues which may still exist in older versions.
    • Due to technical limitations, fixes for some issues cannot be backported to older dotCMS versions at all.
  • Older releases may depend on components which have known issues and security vulnerabilities.
    • All dotCMS releases depend on underlying 3rd party components, such as Java, Tomcat, and log4j.
    • Since these are 3rd party components, dotCMS cannot fix or mitigate any security or performance issues in these components directly.
      • Therefore, upgrading dotCMS to a version which supports newer versions of these components is the only way to resolve these issues.
  • The longer the time between dotCMS upgrades, the more work is required when an upgrade is finally performed.
    • Customers who regularly upgrade require less work and experience fewer difficulties when the upgrade is performed.

In order to ensure that dotCMS can provide effective support for its products, each version of the product is only supported for a specified time after its release.

Support Period

There are two different kinds of dotCMS releases, each with a different support period. During the defined support period, dotCMS may provide patches or workarounds for security or major performance issues.

While dotCMS Support has the responsibility of directly assisting customers and R&D has the technical understanding of the decisions for the above guidelines, neither department will make release decisions in isolation.

  •  R&D regularly meets with Support to determine which issues are providing the most challenges to clients, and direct development resources to resolve those issues.
  • The goal for everyone at dotCMS is to ensure that all customers running dotCMS are successful in their implementations.
Examples
  • dotCMS v5.1.6 was released on 06/6/2019, so it is fully supported until 06/06/2020.
  • dotCMS v5.3.8 was designated as an LTS release on 12/03/2020, so it will be fully supported until at least 06/03/2022.
  • The end of the Support Period (the End of Life date) for each dotCMS release is listed in the Changelogs documentation.

Support Past End of Life

Any release which is past the end of its designated Support Period is considered past its End of Life (EOL).

Enterprise customers who are on releases which are past the EOL will still receive front-line product support. However, there will be limitations to the level of support dotCMS can provide.

  • Patches and hotfixes will be provided for critical security vulnerabilities only, at the discretion of dotCMS.
  • Support will not be provided for features which have been deprecated or removed in all currently supported release versions.
  • Support may be limited or significantly delayed for other features, due to lack of support personnel with experience on older versions.

Long-Term-Supported (LTS) Releases

dotCMS will periodically specify specific product releases as Long-Term Supported (LTS) releases, which will be maintained for a longer period than other dotCMS releases, and which will provide a number of advantages for customers that choose to install them.

  • LTS Patch Releases have a longer support period than other maintenance releases.
    • Each LTS release will be supported for a minimum of 18 months from when that release series was designated as an LTS.
    • This means that customers running LTS releases do not need to upgrade as frequently as customers running the latest Agile releases.
  • dotCMS will periodically deliver LTS Patch Releases, which include proactive fixes for newly discovered issues which most customers have not yet experienced.
    • For technical reasons, not all new fixes may be included in LTS patch releases.
    • dotCMS will determine which fixes can and should be included in each LTS Patch Release, based upon both the impact of the issue and the potential impact of the changes required to implement the fix.
  • LTS Patch Releases are explicitly designed to be installable with minimal risk and without the need for a full upgrade.
    • dotCMS will specifically not include any changes in an LTS patch release which may affect the behavior of existing systems.
    • Most LTS Patch releases can be installed with less than ten minutes down-time on single node systems, and with no down-time on clustered instances.
  • Upgrading between LTS releases will have lower impact than upgrades between other releases.
    • Since most dotCMS customers upgrade between LTS releases, the upgrade path from one LTS release to another is well established, and easier for both the customer and dotCMS staff.

For more information on the advantages of LTS releases, please see the Long-Term-Supported (LTS) Releases documentation.

Breaking Change Releases

dotCMS will periodically specify a release as a Breaking Change release. This designation does not change the support provided for the release; the purpose is to make it easier for customers to estimate the level of effort that may be necessary to migrate to the newer release.

A Breaking Change release:

  • Has significant functionality or architecture changes.
  • May include changes in default behavior, that will require changes to your site to maintain existing behavior.
  • May take extra time to upgrade, in the form of configuration changes or data migration.

All Breaking Change releases will be identified in the Changelogs with the icon: