Liferay-Require-SchemaVersion Changes Since DXP Release

If you plan to patch Liferay DXP, note that it is theoretically possible that you will be unable to revert back to an earlier version of DXP due to module upgrades that are automatically executed after you've applied your patch. If you attempt to revert back, seemingly random parts of Liferay will suddenly stop working. The reason this happens is that you've passed through a Liferay-Require-SchemaVersion change. This page documents when those changes have happened.

Warning: This is NOT an official Liferay tool, nor is it supported by Liferay in any way. This does a source code analysis of the code that exists at the tag for the specified release. For Marketplace plugins (which are not recreated from source but rather released on a separate schedule), these versions will not be accurate.

Choose Your Comparison

Note: Entries with a gray background indicate a version change. Version 0.0.0 means that the module does not exist in that version of DXP. If no Liferay-Require-SchemaVersion is specified, the service has an implicit schema version, but this is not treated as a requirement for registering service builder services as components and so is not a breaking change until the schema version becomes explicit.

Starting VersionCheck Against VersionName FilterBreaking Changes Only

Comparison Results

Note: Entries with a gray background indicate a version change. Version 0.0.0 means that the module does not exist in that version of DXP. If no Liferay-Require-SchemaVersion is specified, the service has an implicit schema version, but this is not treated as a requirement for registering service builder services as components and so is not a breaking change until the schema version becomes explicit.

 

About the Comparison

The publicly documented purpose for Liferay-Require-SchemaVersion is to determine if a module upgrade process needs to run.

The undocumented purpose is that it creates a point of no return for service builder services provided by the module.

Essentially, this value is recorded inside of the database in the Release table once all the module upgrades complete. If the value in the database does not match the value in the bnd.bnd, certain things will fail to happen and the service builder services will not be provided to other modules.

At a technical level, when Liferay initializes, the code responsible for injecting service builder services (or really, all Spring components) as OSGi components declares that it needs the value specified in bnd.bnd as a dependency (thus the "requires schema version"), while the value in the database is what's actually published. This means that if the two do not match, service builder services will not be made available, thus creating a point of no return.

What this means is that if a Liferay-Require-SchemaVersion is changed in a fix pack and a customer applies the fix pack, they cannot rollback to an earlier fix pack without some components failing to start (because they depended on the service being available).

You can sometimes work around the issue by deploying the newer version of the module to osgi/marketplace/override, but this will not work if there has been a notable package version change (see Package Version Changes Since DXP Release for additional information) in any of the modules that the service builder module consumes.