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.
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 18.104.22.168
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.