AnsweredAssumed Answered

Alfresco Release numbering

Question asked by loftux Moderator on Mar 25, 2010
Latest reply on Dec 22, 2010 by heiko.robert
I would like Alfresco starting from 3.3 release
-Use an intuitive release numbering scheme.
-Avoid marketing labels in the release numbering.

Why?
Alfresco has a history of very confusing release numbering. I kind of hope that after LABS confusion, 3.2 would make things clear again. But then came community 3.2r and 3.2.r2. I've met people that thought the r meant release candidate (and r2 release candidate 2), thus using 3.2 instead. A bit of the same confusion with enterprise, is 3.2r a service release or only for users that needs RM?
The r to me was a marketing label that could have been put elsewhere.

I understand that there really are no service release for community version, and that may be a reason Alfresco is avoiding calling it 3.2.1. But if you release another 3.2 build, give it a sequence number, and explain on the accompanying documentation instead that this is not a service release, and may introduce new features and possibly bugs. By doing this, user new to Alfresco will not have a so hard time to understand what version is the latest.

Looking at Jira, https://issues.alfresco.com/jira/browse/ETHREEOH#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel the later shows that there will be a 3.2 SP1 for enterprise in april? But what was version 3.2r enterprise then?

If you have a consistent system, it also makes it easier for amp module development. I try to number the amp modules for the swedish language pack, let say for release 3.3 it will be 3.3.0.x where x is a release number for the language pack. Makes it very easy to understand what version the language pack is it is intended for.

So maybe this can work?
Community: 3.3.x (there may never be a 3.3.1, but if)
Enterpries: 3.3 SPx, clearly indicating that this is a service release, but easily translatable to 3.3.x scheme.
This is pretty much what you are doing for enterprise, but avoid things like the Enterprise 3.2r, maybe should have been 3.3 if it is a new dev branch. And put some space in the community version numbering giving it even numbers, like 3.4, 3.6, thus you have room for a new intermediate odd release number both for community and enterprise if you ever want to make an "r" like release.

I'm not arguing that my suggestion is the best, but please have a release numbering that is more intuitive, more predictable and avoids confusion.

Outcomes