Migrating from Enterprise Edition (5.1.1.4) to Community Edition

[psrun]

Hi,

We wish to migrate from Enterprise Edition to Community Edition. The Enterprise source version is 5.1.1.4. We choosed the latest 5.1.x Community Edition that is 5.1.g as the target version. We followed the following Alfresco rule : to migrate from M.m.p version of Enterprise Edition, chose the latest M.m.x version of Community Edition (x=g that is the most recent letter in the version, if M.m=5.1). But we meet some problems with alfresco 5.1.g WAR :

- it embeds many 5.2.a jars

- the displayed version is 5.2.0 instead of 5.1.g

So this is my question : is 5.1.g the right version for our migration ?

If so, why 5.1.g alfresco war embeds 5.2.a jars ? Is it normal ? Which are the risks ?

if not, which target version should we take ? Should we migrate from 5.1.1.4 to 5.1.f or 5.1.e instead ?

Thank you in advance for your help.

Best regards

[afaust · Accepted solution]

5.1.g is a bit of a problematic version as to how it relates to GA/EA releases, since some of the artifacts on artifacts.alfresco.com include some early-access (EA) 5.2 libraries. As far as I am aware, the "dirty parts" affect the Repository+Share Services WAR (org.alfresco:alfresco:war:5.1.g) which contains 5.2.a libraries since it originates from 201606 EA. Only by doing a manual install using 5.1.g for Repository from 201605 GA and 5.1.g from 201606 EA for Share will you get a clean, correct setup.

I would typically pick the next major version up when moving to Community Edition. 5.1.g is a lower / less advanced version than 5.1.1.4, meaning that 5.1.1.4 could have already introduced minor schema changes that may not be compatible with 5.1.g. If 5.2 were used, it should detect that the previous 5.1.1.4 is of a lower version and check which changes need to be made to the schema to upgrade to 5.2 proper., potentially leaving out patches that have already run as part of the 5.1.1.4 Enterprise version.

NOTE: This reply was updated to correct some mistaken statements - original reply:

5.1.g (I believe it was 201605 GA) was a bit of a dirty release, since some of the download bundles included some early-access (EA) 5.2 libraries. As far as I am aware, the "dirty parts" affect primarily the Share user interface. Only by doing a manual install using 5.1.g for Repository from 201605 and 5.1.f from 201604 for Share will you get a clean, correct setup (there is no 5.1.g for Share).

I would typically pick the next major version up when moving to Community Edition. 5.1.g is a lower / less advanced version than 5.1.1.4, meaning that 5.1.1.4 could have already introduced minor schema changes that may not be compatible with 5.1.g. If 5.2 were used, it should detect that the previous 5.1.1.4 is of a lower version and check which changes need to be made to the schema to upgrade to 5.2 proper., potentially leaving out patches that have already run as part of the 5.1.1.4 Enterprise version.

[psrun]

Hi Axel,

Thank you for your reply. We noticed that alfresco-5.1.g war contains 5.1.g (e.g. alfresco-share-services-5.1.g.jar)  and 5.2.a jars (e.g. : alfresco-repository-5.2.a-EA.jar,alfresco-mbeans-5.2.a-EA.jar ) but not share-5.1.g. war. Share only contains 5.1.g jars and correctly display 5.1.g. We downloaded alfresco and share wars from Alfresco Maven private repository.

I was not precise enough : we have not deployed 5.1.1.4 yet and will not do. Actually, we will directly deploy in 5.1(g?) Community Edition. So it is not really a migration but simply a development change. So we will not meet the problem with the database patch. I wish to stay in 5.1 version because we nearly finished our custom development and want to minimize additional work et bugs risks with 5.2.

So I wonder if I should take 5.1.f instead of 5.1.g for this.

Putchhat

[afaust]

Alfresco 5.1.g is perfectly fine and I use it for production deployments at customers. You just have to make sure to use a combination of artifacts that does not include the 5.2 EA libraries. I have both 5.1.g Repository/platform and 5.1.g Share at my customers. It is easiest if you do not use the installer and instead do a proper, manual installation with WAR files retrieved from the Alfresco Maven repository (artifacts.alfresco.com).

[resplin]

One key correction for people that don't read the entire thread:

201605 GA was not a dirty release. It met our standards for a Generally Available release. The original questioner was installing 201606 EA, which was an early access release. The release notes for that release clearly state that it includes a 5.2.a EA repository WAR in order for Alfresco to get feedback on the new REST APIs.

And a couple of hints:

In the future, the Share and Repository version numbers will drift further out of sync similar to how RM and Search Services have their own version numbers. You will need to pay attention to the GA / EA labels and the Release Notes in order to see what versions are intended to be used together. But as our API stability continues to improve there will be more compatibility between releases.

Also it is highly recommend that people who adopt Alfresco Community Edition keep pace with the latest GA releases, as we do not generally backport fixes to previous releases.

[afaust]

I have gone and modified my response to clarify what is dirty / problematic...

[resplin]

Thank you Axel. As usual, your responses are really helpful. But I think your answer still misses my main point, which is that all a person has to do to get a clean release is to use the 201605GA release.

I think there are three sources of confusion:

• People think that the Content Repository 5.1.g (shipped in 201605 GA) needs to match the Share 5.1.g (shipped in 201606 EA), but they don't. Share's version number is not directly tied to the repository. As stated in the 201606 EA release notes, you are correct that there are some useful bug fixes if a person chooses to deploy Share 5.1.g with the Repository 5.1.g, but it isn't incorrect to use the 201605 GA release out-of-the-box.
• The version numbers simply reflect how many releases were done during that version's lifecycle, for example "g" is the seventh release of the 5.1 Share. Sometimes a component of Alfresco Community Edition doesn't change between monthly releases, and so we include the same artifact in multiple releases. This is why the versions get out of step. People don't seem concerned when this happens with the SDK, RM, or Search, but because Share and the Repository used to be released in lock-step it causes some confusion.
• Share reports in the UI it's version number, which people then think applies to the Content Repository. This is further confused because we still have the habit of referring to both Share and the Content Repository together as a "5.2 Release" when market our commercial products.

Thank you for giving me the opportunity to clarify how this works. Hopefully it helps others understand our thinking. We are open to suggestions for improvements.

[afaust]

Your explanations are fine for a casual user that should normally not care about the low-level, technical versions. But when someone asks regarding the technical versions I will focus my answer on these, and regard the GA/EA numbers as "marketing versions".

You are right, Share and Repository do not have to match - but if you want to have the latest of both (5.1.g) you have to do it manually. And 5.1.g was mentioned as the target version by the original poster. I did not intend to discourage to use any of the releases "as-is" - I just focused on the steps necessary to get a clean, pure 5.1.g setup, which is hindered by the fact that the org.alfresco:alfresco:war:5.1.g Maven artifact contains 5.2.a repository JARs, which is confusing - and frankly incorrect - because the version number of included share-services defines the version of a Repository artifact in this case. It would all be perfectly fine if that Maven artifact was tagged as the 201606EA instead of 5.1.g.

[psrun]

Do you mean I can safely replace every 5.2.a dependencies (e.g. alfresco-repository-5.2.a-EA.jar,alfresco-mbeans-5.2.a-EA.jar) with 5.1.g dependences (e.g. alfresco-repository-5.1.g,alfresco-mbeans-5.1.g.jar) to build alfresco.war ? Have you done that for your alfresco-5.1.g at your customers ? Why was the original alfresco-5.1.g.war artefact built with 5.2.a dependencies ? Was it simply a bug in the depedencies ?

[psrun]

Sorry to insist but I'd like to be sure that replacing 5.2.a dependencies qith 5.1.g dependencies is a correct operation and will not produce errors.

Thank you