Alfresco Community Edition needs sensible version labels

See if you can answer this question: What is the current stable release of Alfresco Community Edition?

Some of you probably blurted out “5.0”. But that’s not specific enough. Alfresco Community Edition releases have letters as part of the release name. Did I hear someone say “5.0.c”? That is certainly the latest version but is that the current stable release? I would argue that it’s not and that the correct answer to the question is actually “4.2.f”. That’s the newest version I would recommend to anyone wanting to run Community Edition in production.

The problem is that you can’t actually tell what is supposed to be the stable release by looking at the version labels like you can with virtually every other open source software project. Hindsight is actually the only tool we have. The reason 4.2.f is the latest stable release is because it was the last release in the 4.2 Community Edition code line. We won’t know which 5.0 release is the stable one until Alfresco stops creating 5.0 releases!

Really, 5.0.a, 5.0.b, and 5.0.c should be labeled 5.0-RC1, 5.0-RC2, and 5.0-RC3. I’m using RC for “Release Candidate” here because that’s basically what they are, but “snapshot” or “milestone” could also work. We just need something that indicates that, eventually, we’re going to see an end to the iterations and finally arrive on a stable release and that you should really wait to deploy to production until that stable release comes out.

If you look at 4.2, I think 4.2.e was the “final” release and then 4.2.f was a special release to address a serious security vulnerability. So 4.2, a, b, c, and d should have been “release candidates”, 4.2.e should have just been 4.2.0, and 4.2.f should have been 4.2.1. I wouldn’t expect the third digit, which normally signifies a “service pack” to be anything other than 0 for the vast majority of Community Edition releases. The 4.2.f release was an exception to the norm which is that Alfresco doesn’t provide service packs for CE.

The reason an easily identifiable release label is important is because today people in the community are going to the Alfresco download page and assuming that what they are downloading is a stable release. They are then installing and running that release in production. This leaves those people disappointed down the road when they find out they installed software with numerous known issues or partly-implemented features (I know those issues are often documented in the release notes and in Jira). The point is that downloaders, particularly newcomers, don’t have (and shouldn’t need) the insight that Alfresco releases don’t really settle down until the fourth iteration or so. That should be explicit.

The reason Alfresco doesn’t use “stable” to describe the release is partly commercial. The thinking is that doing so makes running the freely-available Community Edition in production seem less risky or even encouraged by the company that depends on revenue from the paid edition.

The other challenge is about process. I don’t think engineering always knows that a given Community Edition release is going to be the last one until after the fact.

Both of these could be addressed with a mindset change. Instead of “Let’s iterate on release X.0 until we’re ready to work on the next major release” the thinking ought to be, “Let’s drive toward a stable, production-ready X.0 release and once we think we have it, let’s call it that”.

I’ve heard chatter that Alfresco might, at some point, consider offering support for those running CE. Based on the number of SMB’s who have told me that Alfresco One is out-of-reach for them financially, there ought to be a strong demand for a low-priced subscription around Community Edition. If that happens, I assume both the mentality and the process around CE version labels will get cleaned up. But I hope we don’t have to wait.

17 comments

  1. Bindu Wavell says:

    In fact I think we have the same issue with Enterprise. While 4.2.0 and 5.0.0 are way more stable than 4.2a and 5.0a, our general experience is that these releases are not ready for production usage. Typically we wait for one or ideally even two minor releases. For example, in the 4.2.1 hotfix stream things seemed to stabilize for 4.2.x.

  2. Samuel Langlois says:

    Thanks for this interesting point of view!

    Here is an information that may help, which Alfresco should probably have advertised more: Alfresco 5.0.c Community and Alfresco 5.0 Enterprise are based on *exactly* the same code base. The difference is that the Enterprise edition contains more modules.
    This means that 5.0.c could arguably be called the latest stable version of the Community Edition – and certainly not a simple 5.0-RC3.

    More generally, and that’s my personal opinion, I feel the difference between Community and Enterprise editions will be less and less about quality (because there is a big effort to automate tests and improve quality, which benefits all editions) and more and more about features (because more of them are now reserved for the Enterprise edition: clustering, admin console, MSOffice integration, etc.)

  3. Richard Esplin says:

    Some quick clarifications for you readers.

    Currently Alfresco Community Edition uses a letter scheme (4.2.a . . . 4.2.f) and Enterprise Edition uses a number scheme (4.2.0 . . . 4.2.3).

    We have tried to do a better job in the Release Notes clarifying the maturity of each release of Community Edition.

    I consider 5.0.c to be a mature release. We are currently working on 5.1.a.

    We certainly understand the need, and as Jeff mentioned, have looked at different solutions over the years. But the key thing to understand is that Community Edition releases are a tool used by our engineering team to produce stable Enterprise Edition releases. They are not currently goals in-and-of themselves. Changing that is more than “a simple mind-set change”.

    Thanks for the feedback.

  4. Andreas Steffan says:

    Hallo Jeff,

    I agree that the current CE versioning scheme lacks helpful semantics. In fact, it can even be more confusing. I was expecting breaking (API) changes, a significant overhaul of the third party libraries and big new features in 5.0.a.

    Regarding the low cost subscription, do you know how the Alfresco Team project actually ended up?

    Regards
    Andreas

  5. Angel Borroy says:

    I agree with your point of view: another Community release naming is required.
    But what about Alfresco 4.2.c?
    I think it’s a pretty stable version and it have only minor issues. 4.2.d and ahead, from my point of view, it’s another major version because they include major functionalities.
    And I think that 5.0.c, from a functional perspective, it’s also a closed version. It can be argued that there are some platform support lacks in this release, but it works pretty well and it have no big issues.

  6. Jeff Potts says:

    Richard,

    Imagine how much you would do for the community by making a production-worthy Community Edition release a goal! And that, in turn, would drive more stable Enterprise Edition releases because more people would use Community Edition and give you that feedback you want. I never said that such a mind-set change would be easy. I know far too well how seismic of a shift that would be. But a fella can dream, can’t he?

    In hindsight, I think the decision to split the code lines turned out to be a poor one. It complicates the build and it causes confusion in the public. I’ve been doing a lot of work with Elasticsearch lately as well as some Ansible. They both have a core product that is open source for which they offer support and add-on, value-add products. I can’t imagine how much easier that must make things internally for Engineering. And as an implementer, it is also very easy to get started and then flip a switch on support when I’m ready.

    Alfresco should have followed this model. They could have made the core repo completely open and the same exact software (single code line) regardless of whether or not it is being commercially supported. Then they could have made Explorer/Share an add-on. Same for transformations and so on. I don’t think it is too late for something like that, but I’m not sure it fits in with either the price point Alfresco is going for these days or for the adoption rate, which is much lower than lower-level technology components like Elasticsearch, Ansible, etc.

    Jeff

  7. Jeff Potts says:

    Samuel,

    As the distinction disappears, maybe you can go to a single release of “the repository” that is the exact same distribution whether or not it is commercially supported or not. That would probably help things out a lot. After all, if the distinction isn’t there, why the separate downloads? Clustering could be handled with a license. In fact, I think it handled that way now in Enterprise anyway. And JMX, well that ought to be in Community Edition anyway. It’s not a differentiator.

    Wouldn’t it be great if people could move from Community Edition to Enterprise Edition simply by dropping in a license file? You’d get a lot more upgrades, I’ll bet.

    Jeff

  8. Pingback: What’s new in Alfresco Community Edition 5.1? | ECM Architect

Comments are closed.