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 are EOL (End of Life'd). 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 such support.
The following chart shows the planned support lifecycles for previously released versions of dotCMS. For more information on the dotCMS release and lifecycle policy, please see below.
The dotCMS Release Lifecycle
The challenge at any software company is that it is only possible to support, QA 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. The idea of having a support team outside of R&D manage a separate “Supported” codebase just adds another piece of software to the complexity.
It is important to note that the support being discussed here is not Help Desk Support - dotCMS support engineers are available and willing to support a dotCMS release until its major release is officially EOLed. Instead, this document describes the product being supported as a codebase.
A Major Release is release where the first number of the version number changes (i.e. 2.x vs. 3.x). Major releases contain things such as significant new features, shifts in the underlying data model, changes to the UI or changes to the front end presentation layer. A Major Release may also contain changes in how objects interact in the system including search, storage, metadata, permissions or content. Major Release upgrades generally require project planning and should not be undertaken lightly.
A Minor Release is a release where the second number in the version number changes (i.e.. 3.2.x to 3.3.0). These releases contain bug fixes as well as new features. The features in a Minor Release can vary in degree but as a rule should not manipulate the existing data model of dotCMS, though a Minor Release can extend the current data model with a new column or table. Minor Releases should upgrade cleanly with few issues.
A Patch Release is a release where the third number in the version number changes (i.e. 3.0 to 3.0.1 or 3.2.1 to 3.2.2). The purpose of the minor release is general bug fixes and improvements needed for stability. The minor release should be thought of as a maintenance release. Its purpose is to bring stability to a minor release. Patch Releases should upgrade cleanly with no issues.
- The codebase of a Major Release will be supported a minimum of 3 years from the time it originally was released. As an example, dotCMS released version 2.0 on May 4, 2012, and as such, dotCMS will provide Patch Releases, as needed, until at least May 4, 2015.
- The last released version of the previous Major Release will be supported a minimum of 12 months from the time of the release of the newer Major Version. As an example, the dotCMS 3.0 was released on November 18, 2014. Customers expecting support that are still running the version 2.x series should be on the last release of version 2.x (2.5.7), which dotCMS will support until December 18, 2015.
- Patch Releases will be available to current and previous Minor Release of the current Major version. As an example, a customer running version 3.0 can expect patch fixes to their version even as version 3.1 is released. Once version 3.2 is released, customers expecting patch fixes would need to upgrade to the now current version (3.2) or the previous supported version (3.1) in order to receive fixes via a Patch Release.
- Naturally the patches for the previous Major Release slow down with the release of a new Major Release. As always, any needed security or major performance issues will be patched and addressed if workarounds cannot be easily applied.
- While 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 a box. R&D meets with Support to determine which issues are providing the most challenges to clients. The goal for everyone at dotCMS is to insure that customers running dotCMS be successful in their implementations.