nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Upgrade Path Questions

michaelp

I have to upgrade from 5.1 to 7.0 and the Upgrade Path says I have to install 5.2 first.

I can also upgrade from 5.1 to 6.2 and then to 7.0.

So I see that all the upgrade paths overlap each other, but they don't support going straight from 5.1 to 7.0 ???

Makes no sense to me so I wanted to ask for what reason we even have to "make a stop" at older versions??

From a technical POV the latest version already includes all Patches so what is going on here?

And should I upgrade to 5.2 or 6.2 first ???

And is it enough to just run the "intermediate version" alfresco.war without the final plugins/modules/full configuration so only the DB Patches will get applied (alfresco won't fully start I guess because of subsystems failing being not fully configured)?

Find more posts tagged with

Alfresco Content Services

Comments

afaust

The documented upgrade paths basically only reflect which paths have been explicitly tested and verified. It makes sense for Alfresco to only test / verify upgrades from the last / most recent / next version to go out of full support when a new version is released, which is why they only tested from 5.2 to 7.0, but not 5.1 to 7.0, because 5.1 was already out of support for quite a while, and 5.2 was the most recent version to be deprecated at the time 7.0 came out. It can technically work to upgrade from 5.1 to 7.0, but you'd have to test / try it on your own risk.

The general rule (for Enterprise) also has always been to first upgrade to the latest version in a specific release (e.g. the latest service pack) before doing an upgrade to a higher major/minor version, as these service packs could include important fixes that later versions with their upgrade logic might rely on.

Also, the latest version does not include all patches. Alfresco has been known to disable / remove some intermediary patches (e.g. for upgrades between 5.x and 5.x+1) in the major release after next (which would be 7.0), for the purpose of reducing support and maintenance costs. It is also for that reason, that straight upgrades are generally only officially supported from 5.2 to 7.0, because in that case, you are not in danger of potentially missing out on fixes from those intermediary patches.

You can upgrade to 5.2 or 6.2 first - your choice really, as long as you ensure that you had the chance to run any intermediary patches relevant for a current 5.1 install.

If you have custom models in your plugins / modules, then you must ensure that those models are available and registered with Alfresco for the purpose of an upgrade using the intermediate version WAR, otherwise some patches may run into issues when dealing with nodes of affected types, aspect, or with affected properties, associations. You typically do not have to have a fully-fledged configuration, or full installation of all modules.

michaelp

Hi @afaust,

Many thanks for your detailed answer, it helped alot!

But since I have the master himself on line here let me ask some more quesions:

Is there a difference between those two strategies:

5.1 > 5.2 > 7.0

5.1 > 6.2 > 7.0

or are they equally good? or is the best:

5.1 > 5.2 > 6.2 > 7.0

to get "all" patches?

"Alfresco has been known to disable / remove some intermediary patches" sounds not really smart to me, a DB Schema versioning mechanism is exactly the reson to ensure that all patches are applied so the final Schema is always the exact same so that you actually DON'T run into "danger of potentially missing out on fixes" ... but I don't have to understand what Alfresco is doing here ... but does this also apply to the Community version where Alfresco (the company) is removing patches from the (Open Source) Community repository?

I am in the situation where I have to upgare a couple of modules too which some of them override OOTB webscripts, add Behaviours, Workflows, etc., so is it safe to ignore all of those customizations and just install the content model(s) (and really nothing else) while running the intermediate patches (I don't want to upgrade all modules once for each intermediate version, upgrading the OOTB webscripts just once is punishing enough ...)?

Again @afaust , many thanks for your time and the effort you put into your answers!!!

afaust

So, expectation-wise, there should be no differences between 5.1 > 5.2 > 7.0 and 5.1 > 6.2 > 7.0, and 5.1 > 5.2 > 6.2 > 7.0 just seems overly cautious. Unfortunately, I myself did not yet have such an "old" starting system to try any of the routes. But I do have an Enterprise customer that intends to go from 5.1.1.x to 7.0 this year, and we are planning to go the 5.1 > 5.2 > 7.0 way, as I have already had upgrades from 5.2 straight to 7.0 without hiccups.

Not all patches are actual DB schema patches. The DB schema ones you can still find in all Alfresco versions. But some meta-level patches dealing with certain states of nodes / properties / mimetypes etc. especially between different versions of (Enterprise) Service Packs / Hot Fixes, and other minor release differences, those may be disabled / removed to keep the code base manageable. Luckily, nowadays, they are mostly well organised in https://github.com/Alfresco/alfresco-community-repo/blob/master/repository/src/main/resources/alfresco/patch/retired-patches-context.xml

And of course this fully applies to Alfresco Community Edition. The entire software development process is controlled and owned by Alfresco - there is no direct commit access to anyone outside of the company or its network of contracted parties. One should not make the mistake and apply a certain model of open source management to the Community Edition that you might find in "truly" open source projects of the Apache Software Foundation, or in the GNU world.

Since I don't know the specifics of the customisations done e.g. in behaviours, I cannot state with absolute certainty that it would be safe to omit them for the intermediate upgrade step. But I can state that I never include them for those "one start only just to let the patches run" steps. Webscripts and all services / components which provide an API to the customisations can be safely ignored in all instances, since you should never allow anyone to access those APIs during the intermediate steps anyway. This includes jobs and anything running in the background. If you have workflows, it might also be worth to disable the Activiti engine during the intermediate step.
Coming back again to that Enterprise customer, any code upgades are exclusively planned to target the final 7.0 version.

Shaul1

Your upgrade path is a detailed plan for what you will upgrade and when. ... If you have assessed your deployment—that is, you know what you have and what you want—you are ready to build your upgrade path. Upgrade paths that require intermediate versions can be time consuming.

AdvancedMD Patient Portal