We have SAP Hybris Commerce version 5.1.1 with custom extensions installed. Now we need to upgrade it to newest version 6.2.
My question is: Can we upgrade it to 6.2 and skip all versions between 5.1 and 6.2? Or must it be done by upgrading to 5.2, then to 5.3 and so on?
Yep - 5.1.1 to 6.2 ought to work (I've been working on a project that's done exactly this).
You will probably have to make some changes - watch out for any customisations you've made - it might be worth reading through the release docs to have an idea of what's changed - off the top of my head the structure of add ons is one area that's a bit different between 5.1 and 6.2, but otherwise things should work OK in theory.
Yes you can directly update to 6.2.
It's important to regulary update your hybris version. You should not have so much gap with current version. Indeed it become tougher to migrate your custom code.
Upgrading each minor version in a row is totally useless most of the time. Only do this if you have issues you can't solve while migrating to the target version.
You should take a look at this migration documentation and this guide (it can be used even if it doesn't match your version).
Note that some stuff like promotion are totally different in hybris 6 so you can expect some trouble to migrate everything. Take care of your extensions generated with old template also.
5.5.1 introduces JDK8 and Spring 4, I would not underestimate this change! Depending on the size of your project I would first go for 5.5.1. Also notice the MySQL change for 6.2 (5.6). Don't forget to declare deployment tables in your items.xml. Search for "third-party compatibility" and "release notes" on the wiki. Also try shifting to the backoffice since the hMC is marked as deprecated.
Yes you can migrate directly 6.2.
The time and difficulty depends on your custom code (and how much it respects good practices : naming conventions, usage of service, architecture respect...etc)
You might also consider that HMC is deprecated in 6.2
Related
I have just upgraded myself to new version and started development in 9.0.1 Revision 20131022.0932 ( release 9.0.1). I have couple of small queries.
1) Am I using the right version for development or need to upgrade by implementing patches etc?. This is stable for development?
2) Previously I was developing applications on 8.5.2 but my clients were on 8.5.x and 9.x.
This migration is safe for existing applications? no crashes? no code mismatch? Is their any guideline for developer? Co-Existence of clients is possible?
Please guide me and thanks in advance
Best Regards,
Qaiser
In general, upgrading to the latest Designer version is ideal, especially with (as Per recommends) the latest fix packs, as well as on the server.
For non-XPage design elements, there should be no incompatibilities with 8.5.x through 9.0.1, so you're good there.
If you do XPages intended to be rendered by older versions (either older servers or XPiNC in older clients), you could run into trouble there, using properties and controls that don't exist there. You can mitigate that a bit by going to the app's "Xsp Properties" in Designer and changing the "Minimum Supported Release". That won't help you avoid trouble with third-party plugins not installed everywhere, but it helps with the core runtime controls.
I would like to ask a question about wether or not I should do the migration to Liferay 6.2.
Me and my team are working since 4 month on a portal quite big developed with Liferay 6.1 (CE edition) and now, since the project publication date is still 4-5 month ahead (so I do have time), I was wondering if doing the migration to 6.2 now is a good choice.
I already tried the new version and I must say I am impressed about the new features and since now I haven't find any bugs.
Anyone had any experience on developing portlet/themes on Liferay 6.2? Is is worth it to do the migration now or shall I wait for the next ga2 release?
Any suggestion is very welcome.
Thanks
Depends mostly on the kind of work you've done on that portal. Even slight upgrades in Liferay, can have major differences in the source code. If this affects the work you've done, it will affect the upgrade too. For example, things will get difficult to update if :
You have developed custom portlets, as they will need recompilation for the new runtime
Developed Portlets that use ServiceBuilder might need more work than just a recompilation
Using Hooks (even simple jsp hooks) might need re-writing. ext hooks will almost certainly need to, and it can become a major pain
On, the other hand, if most of your work had to do with light theming and content management, it could become an relatively easy and painless upgrade.
In any case, make sure to keep a backup of your Liferay Database, because once you upgrade, there is no way to downgrade back to the initial version.
As you're using CE, my recommendation is to upgrade as soon as possible. Reason is that there are no more updates for 6.1, now that 6.2 is out. If you're going live in 5 months, you'd be on a version that's unsupported for half a year at the date of publication.
The alternative is to go to EE, which is supported for ~5 years from release, e.g. you'll have several years of support in front of you. However, as Liferay is paying my salary, note that I might be biased...
Of course, being unsupported "by Liferay" does not mean that you won't be able to fix any bugs or issues, but you'll have to do this on your own, and sooner or later you should upgrade anyway... If you're not yet live, I'm recommending to do it sooner.
Liferay 6.2 does not (yet) support as many marketplace apps as Liferay 6.1. Also Liferay 6.2 CE has bugs, and patches are available only to EE subscribers; this forced us to use Liferay 6.1 CE instead of 6.2 CE.
You will have issues if you are using the Vaadin framework under Liferay.
Liferay 6.2 CE does not support Vaadin out of the box ... it is delivered with Vaadin 6.8, but it is broken - your portlet code will break.
You would have to consider moving to Vaadin 7.1 at best ... and that is a non-trivial code migration as many items have been deprecated between 6.8 and 7.
I went that route and the learning curve was unexpectedly steep.
We have an application, in which we have series of releases. The current version of the application in production was V2.1
Now we have a set of new UI Screens to be added and related changes to the application. We are planning to release these changes as V3.0.
Do we need to go with Major Upgrade or Minor Upgrade? If we go with Major Upgrade, do we need to reinstall the application? or change the version to 2.2 and go with Minor Upgrade?
Please suggest me some best way to go about with these installers.
Note: We are using Install Shield Premium for building the installer.
If the only changes you are making are to the UI of your installation wizard, there is no fundamental reason to prefer either a minor or a major upgrade over the other. Typically the choice is driven by the changes you are making to the application itself, or the files that comprise it.
A Minor Upgrade will support first-time installations, as well as provide what should be a shorter update for the upgrade experience. A Major Upgrade will uninstall what's currently there before installing the new version. Either can be done with either sets of version numbers - the difference depends primarily on whether you change your ProductCode.
See Patching and Upgrades for details. Some people prefer creating Major Upgrades because they are easier to reason about.
The latest stable release of Mono right now is 2.4.2.3. Does subsonic 3 work with it? I know Mono isn't compatible with all .net 3.5 features yet, but I'm presuming compatibility depends on which specific language features of .net 3.5 Subsonic uses. Does anyone know for a fact whether it's compatible?
Its compatible - just remember to use an actual version of MySQL connector, if planning to use MySQL.
And there is an Error in current SubSonic (see Issue 111). Change IsDbNull to IsDBNull in SubSonic.Core/Linq/Structure/ExecutionBuilder.cs and recompile.
That did it for me with Mono 2.6 and MySQL-connector 6.2.2
But I didnt't test anything but simple save and read queries.
from the looks of the code not everything seems to be full hilt 3.5 so i would cast an opinion that it will be just fine, i have been using 3.0.0.3 and resharper comes up with tones of comments about how it can be changed and upgraded.
but it takes less than 5 mins or so to test, so i would go ahead if i was you, you dont really have much to loose other than 5-10 mins.
hope this helps
All Liferay docs seem to suggest that it is necessary to install the Jikes compiler in addition to the JDK. Is this really needed, to do Liferay portlet dev, or can I just suffice with the JDK.
No. As far as I know Jikes was never a strong dependency. It used to be a default compiler for older releases of Liferay. But since version 4.4 they changed to standard javac.
No. We have Liferay 5.2.3 running in a production environment. We've done a few customizations of the liferay core as well as new portlets.
I never installed the Jikes compiler, the JDK was sufficient for every task.
The last two years at least, we've been predominantly building with ecj, which is much, much faster than any JDK compiler I've ever used.
In your build.${user.name}.properties specify
javac.compiler=org.eclipse.jdt.core.JDTCompilerAdapter