Product Numbering and Release Naming

Document created by resplin Employee on Jun 6, 2015Last modified by resplin Employee on Jul 26, 2017
Version 5Show Document
  • View in full screen mode

This document outlines how we name releases of Alfresco Community Edition and number included artifacts in order to set proper expectations about the state of the release.

 

Goals

Our practice around release numbering tries to balance various competing goals:

  • Allow for frequent releases such that open source collaborators can quickly provide feedback on new features.
  • Clearly indicate to users of Alfresco Community Edition when a release is considered stable enough for an upgrade.
  • Decouple the version numbers of the various artifacts that make up a release of Alfresco Community Edition, so that pieces can be released independently.
  • Differentiate the unsupported open source releases from the officially supported releases that make up Alfresco Content Services.
  • As much as possible, follow the industry standards documented in Semantic Versioning.

 

Types of Releases

The artifacts included in Alfresco Community Edition are included in multiple types of releases:

  • Nightly Snapshots
    • Installer bundles: {product name}-{YYYYmmdd}-SNAPSHOT-{build-number}-{deployment target}.{extension} e.g. alfresco-community-installer-20170714-SNAPSHOT-530-linux-x64.bin
    • Artifacts in the bundle: {artifact name}-{version family}-SNAPSHOT.{extension} e.g. alfresco-rm-community-repo-2.6-SNAPSHOT.amp
  • Monthly Release Bundles of Alfresco Community Edition
    • Release bundle: Alfresco Community Edition {YYYYmm} {EA|GA} e.g. Alfresco Community Edition 201707-GA
    • Installer bundle: {product name}-{YYYYmm}-{deployment target}.{extension} e.g. alfresco-community-installer-201707-linux-x64.bin
    • Artifacts in the bundle: {artifact-name}-{version number}.{extension} e.g. alfresco-repository-5.2.g.jar
  • Supported releases of  Alfresco Content Services
    • Release bundle: Alfresco Content Services {Version} {EA} e.g. Alfresco Content Services 5.1.3 or Alfresco Content Services 5.2.0 EA
    • Installer bundle: {product name}-{version number}-{deployment target}.{extension} e.g. alfresco-content-services-installer-5.2.0.1-linux-x64.bin
    • Artifacts in the bundle: {artifact-name}-{version number}.{extension} e.g. alfresco-enterprise-repository-5.2.0.1.jar

Instructions for obtaining these releases is on the page Download and Install Alfresco.

Version Numbers

The version numbers of individual artifacts roughly follows the semantic versioning scheme.

 

Alfresco Support needs to be able to tell when someone is using an officially supported version of the product. To meet that need, the patch numbering of the open source releases of Alfresco Community Edition end in a letter which clearly differentiates them from service pack releases of Alfresco Content Services.

 

Alfresco Community Edition

Major: Number used to identify major releases in functionality that allow major architectural changes and breaking API changes. Examples 3.0, 4.0, 5.0

Minor: Number used to identify minor releases which contain new features but within the same major version family are expected to preserve API compatibility. Examples: 3.1, 3.2,  3.3

Patch: Builds that are publicly released and advance toward the full feature set targeted for that minor version family. Example 3.4.a, 3.4.b, 3.4.c

As a general rule, Alfresco does not release patches for previous versions of Alfresco Community Edition once development has moved on to develop features for the next minor version.

 

Alfresco Enterprise Major.Minor.ServicePack.HotFix

Where:

Major: Number used to identify major releases in functionality that allow major architectural changes and breaking API changes. Examples: 3.0, 4.0, 5.0

Minor: Number used to identify minor releases which contain new features, but within the same major version family are expected to preserve API compatibility. Examples: 3.1, 3.2,  3.3

ServicePack: Number to identify the service pack. Service packs contain bug fixes and are not intended to introduce new features. See the Support Handbook for the official policy on what is included in service packs. Examples: 3.3.1, 3.3.2, 3.3.3

HotFix: Number to identify which hot fix is included in a release. See the Support Handbook for the official policy around hot fixes. Examples 3.3.1.115

 

Denominators of Release Quality

A monthly release bundle is either an Early Access (EA) release or a Generally Available (GA) release. EA releases are intended to provide access to new features to early adopters, and to foster collaborative development. GA releases are intended to be used by people that are new to the products and don't yet have the background to evaluate release quality for themselves. GA releases are the default download.

 

In order to receive the "GA" label, a monthly release bundle needs to:

  • Be of at least equal quality to the previous GA release. Automated tests need to pass, including full integration tests. Usually manual testing on the associated supported product will have progressed such that we have confidence in the release. No blocking issues in open source functionality exist.
  • Be feature complete, and future releases of the same version family are not expected to make breaking changes. All components have a GA quality version and polish such as documentation and translations are also ready.
  • Have an upgrade path to the paid products of Alfresco, though that might be to an EA release of Alfresco Content Services. This avoids problems of people who want support needing to figure out how to downgrade their DB schema in order to migrate to a paid product.

 

Some Alfresco open source projects will have additional releases separate from the cadence of the monthly release bundles. The monthly release bundles pull the most recent releases that meet the goals for that month's release (EA or GA). In order to maintain stability, a GA release might include components from previous release bundles instead of containing the latest version of every Alfresco open source project. Similarly, some EA releases are often of a very high quality but fail to meet the above criteria. It is important to read the release notes for a monthly release bundle in order to understand the specific state of the release. If you are interested in collaborating around the development of individual open source components contained in the release bundle, it is important to follow that specific project in order to be aware of all the releases.

Attachments

    Outcomes