How to Handle the Weekly Releases

Should you consider throwing the latest weekly release directly into production?

David H Nebinger
David H Nebinger
A Minute Read

So just a quick blog post today...

I was working with Support where they were trying to help a client that had a failed U64 bundle upgrade in Production and we were trying to understand what the failure was and help the client complete the upgrade.

Then my friend Christopher Lui happened to mention:

the odd thing is that this customer upgraded their Dev environment to U60, using the exact same steps, properties files, and same 7.3 db, and the upgrade did not get any errors and is usable.

And with that, I was like "well that was the wrong thing to do..."

So, here's the deal with the weekly releases, it applies to both CE as well as DXP...

We are pushing hard to get new features out the door each week, to get new capabilities into your hands as quickly as possible. Although we make every effort to ensure quality on the releases (you would not believe the size of our unit and integration test suites), let's just be honest and say that bugs do slip through...

My recommendation to you, whether you're a client, whether you're a partner, or whether you're a community member, comes down to following this one simple rule:

Treat each weekly release the same way you would treat a custom code deployment.

It's really that simple. You must deploy the weekly release into your lower environments first. You must complete the soup-to-nuts testing of the bundle using your database and your customizations. And finally, you must not promote this to your next level (especially production) until you are satisfied that everything works the way you expect.

This rule is extremely important because there is no support for "rolling back" a bundle update; once you upgrade the database to the new bundle, you're stuck there. The only way you can go backwards is to roll back the database to a state prior to applying the upgrade.

That is, by the way, another recommendation I make: back up your database, your D&M and even your filesystem before applying the bundle upgrade. This will allow for a rollback scenario just in case a new issue is identified and you need to revert to the previous state.

That's it for this post, I'm working on a new one to come out soon using Objects, so I'm going to get back on that now. But hopefully this will help you as you go forward and tackle the weekly updates going forward.

Page Comments
Lee Jordan
2 Years Ago - Edited

"You must deploy the weekly release into your lower environments first. You must complete the soup-to-nuts testing of the bundle using your database and your customizations. And finally, you must not promote this to your next level (especially production) until you are satisfied that everything works the way you expect."

Therein hides a fundamental on paper problem. Liferay isn't as modular as it could be and no customer least of all a community member can be expected to test the entire portal every week to gain one or two updates to one small part of the product that they may or may not have needed.

If the weekly updates applied to a portion of the portal sure, but reading the changelogs is enough to scare the living daylights out of even the most seasoned Liferay user.

Anyone who runs a Linux Desktop Environment regulary will be familiar with this issue of package managment. However as an end user you can't have a seperate machine, even a virtual machine (even if that is a great idea) to run an update to see what it broke. I do run Linux DE's and I do have several machines that I can run an update there before I do over there. With Windows? You can roll back an update and if soemthing goes wrong a revert occurs and it tries again next time.

This rule is extremely important because there is no support for "rolling back".

There used to be. The patch tool was sort of a package manager but not quite. What Liferay needs to get back to is that sense of update integration.

More over another problem with this approach to updates is rolling back. With the patch tool at least there was accountability and ability to roll back, even if rolling back didn't always restiore the previous state. Almost now you would have to back up your entire system in order to roll back.

So every week we are expected to back up the system, read the extensive and exhustive changelogs, dedicate a tester or testing team to regression test the entire update and have another two or three engineers pulled off what they are doing just to compare the custom code that may need to change to accomodate the changes.

Every week?

Regression testing and integrating a fixpack would take at least 3 months if we dedicated a few sprints to it and that was while someone on the team was able to sit on top of the changelogs and highlight potential areas of breakage to other engineers and the QA resource.

Please sign in to reply.
thumbnail
David H Nebinger Lee Jordan
2 Years Ago - Edited

You are not alone in your concern for having weekly releases, and there may soon be an update about that.

In the mean time, I'd recommend maybe avoiding the weekly releases. Start a project on a newer release, stick to that through the development lifecycle, then look to update after you're done and periodically.

Regardless of which release you pick, though, you have to treat it like a custom code release, deploy to dev, test it out, and promote when it passes muster. Even if you're only bumping releases every 2 months, you still follow this process.

RE: Rolling back, yes it was technically allowed, but often didn't work as advertised, especially when the database was structurally changed (as some updates did).

Note that this blog wasn't really advocating trying to apply the weekly updates, it was really more about the "okay I think I'm ready to update, what should I do" concern. All it takes is one too-early deployment to production to ruin your week...

Please sign in to reply.
Lee Jordan
2 Years Ago - Edited

Honestly you have to go back further up the chain too, because I certainly don't trust being able to simply do an update every week. Some of the LPS tickets are very vauge and in the past I've even been led to 404 errors on the pull requests.

We've used Beyond Compare in the past to try to figure stuff out and even then our integration had to go through ideally if there is time our own peer review and regression testing. "Considering maintaining/developing the Linux Kernel one of the most important tasks in the software industry, Linus Torvalds just wants to see things go ahead in the proper way." https://news.itsfoss.com/linus-torvalds-pull-request/

Please sign in to reply.
thumbnail
David H Nebinger Lee Jordan
2 Years Ago - Edited

Beyond Compare isn't always going to provide accurate results though.

Many new development efforts will be in the code, yet they are disabled, hidden behind feature flags which are not enabled by default.

So BC will just give you a lot of false positives since it will identify the changes yet not understand if they are really effective or not.

Please sign in to reply.
Lee Jordan David H Nebinger
2 Years Ago - Edited

Thinking about this some more, it would be very helpful if there was an upgrade assesment tool. Running this tool before applying the update could essentially read the changelog then look at the target destination environment. It's going to scan the properties files and other configurations to help identify potential areas of breakage.

Take the base theme for example, there might be a change to Clay that bumped up its version number, if the tool could read the version number of the custom themes in use it could say "hey you're three versions behind on the theme, maybe run an NPM update and rebuild".

At least that would go someway to help integrate changes.

Please sign in to reply.
Lee Jordan David H Nebinger
2 Years Ago - Edited

And finally, you must not promote this to your next level (especially production) until you are satisfied that everything works the way you expect Let's say we had a particulary busy stretch and because updating Liferay is not our number one task ... We managed to carve out some time to catch up on about 2 months of missed updates. Between Update 60 and 67 there were 1626 documented changes in the changelog. Potentially undocumented changes also. By the time we managed to get Update 67 out to production the latest update might be at 82, optimistically we are behind on about 643 updates now. We'll forever be behind, no matter how many resources we can devote to updating Liferay.

It takes time to get through those levels of lower environments too. Anything that can help us keep pace with these changes by way of automation really would help.

Please sign in to reply.

Related Assets...

No Results Found

More Blog Entries...

Ben Turner
October 21, 2025
Michael Wall
October 14, 2025
YOGESH CHANDRA
October 08, 2025