Alfresco Release numbering

[loftux]

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

[pmyers]

I believe that the 3.2r includes records management module which was not included in the 3.2 release.  The community 3.2r2 I believe was a upgrade from supporting CMIS .61 to CMIS 1.0 Committee Draft 04.

[loftux]

pmyers, you are correct, it was the records management release, hence the r. But as I was saying, it is kind of confusing to know which is/was the latest one.
Community 3.3 is released, and shortly there will be a 3.3G release. Why will it be named G?
If not using number, why will the release not be name 3.3 A, 3.3 B and so on in a more intuitive way.

[mwildam]

I was interpreting the r as "revision" - so r2 as revision 2. :-]

So I can sign that version numbering is confusing.

[mrogers]

+1 that its confusing.  The battle for sensible release numbers was won for one brief moment at the end of the Labs releases and then lost again.     I'm loosing the will to live…

Its best not to read too much into the community version numbers, they are not consistent and have never "meant" anything, in particular nothing to do with "alpha quality" etc.

If there are words that should be added to the release notes then please add them or if its one of the few pages that are locked then post your content here and I'll add it for you.   

As far as I'm concerned 3.2r should have been 3.3. :? 
I don't know what the 3.2 r2 "stood" for.   What it was was was an update of community 3.2 r with an update to the CMIS interfaces to version 1.0.   It also had some fixes from 3.2 Enterprise.
3.3 is the community 3.3 release.
3.3 G will have new functionality for "Google Docs"  (The G is for Google) and it will have a few more bug fixes.

After that its 3.4.

[jpotts]

Wow. G for "Google Docs". That is truly annoying.

+1 for a rational, predictable, marketing-free Community release numbering scheme.

Jeff

[jpfi]

hi,
why not 3.3.1 instead of 3.3G?
cheers,
jan

[nancyg]

Guys -

Thanks for the input on release numbers. I'll make sure that the team who is in charge of naming/numbering releases gets the feedback.

Nancy

[elibra]

+1 that its confusing.
Marketing announcements go faster than release builds
and users are confused expecting its availability in current release.
-(for example being impresed by marketing news like google docs integration or custom lists… )

Suggestion:

What if include more information in Release notes?
- SVN revision number , build number ?

e.g. "Release Version: Community - v3.3.0 (2765), SVN Revision #19754"

   
As build number is usually shown  in System Information of Alfresco Explorrer Administration console:

Version: Community - v3.3.0 (2765)
   
Repository Properties:
Property   Value
Installed Schema   3300
Installed Version   3.2.0 (r2 2440)
Server Schema   4009
Server Version   3.3.0 (2765)

what do you think?

[heiko_robert]

+1 for a consistent and more clear numbering.
+10 for elibra's suggestion
In the past the svn rev # were stated in the release notes. but for 3.4c it's missing again
It would be very helpful if you just put a small text file into every release with all the numbers…

@PM: it would be very helpful if your naming scheme reflects common best practice in (final) releases. For now I read:
3.4.a: early alpha, just for testing, don't use
3.4.b: beta software, nice to try but still known issues and not ready for dayly use
3.4.c: ??? At least a note about the status of work would be nice…
Come on guys, be brave and define a release if you think you're ready and respect common release numbering rules!

Thanks
Heiko