Liferay Subscription Services seeks to resolve unintended functionality, otherwise known as product defects, via patching or configuration changes to Liferay Digital Experience Platform, Liferay Portal EE, and Liferay Commerce ("the product"). Reported issues must be reproduced by Subscription Services in an uncustomized product instance. Some reported issues (e.g., API issues) can be verified and reproduced with a specific reporting mechanism.
For detailed policies please review the following sections:
Commerce 2.x and Below
Emergency fixes for Liferay Commerce will be made available on the latest micro version of a customer's minor version. Customers may be required to upgrade to the latest minor version available in order to receive a maintenance release.
Liferay Commerce releases and DXP fix packs should be updated together since both versions are maintenance releases. When updating a DXP fix pack, it is best practice to update to the latest micro version of Liferay Commerce. When updating Liferay Commerce, it is best practice to update to the latest DXP fix pack available.
Any behaviors or issues that conflict with the product's intended functionality may be resolved via patching or configuration changes to the product. The official documentation for the product determines this functionality.
- Liferay Commerce Admin Guide
- Liferay DXP 7.4 Documentation
- Liferay DXP 7.3 Documentation
- Liferay DXP 7.2 Documentation
- Liferay DXP 7.1 Documentation
- Liferay DXP 7.0 Documentation
- Liferay Portal 6.2 EE Documentation
- Liferay Portal 6.1 EE Documentation
If an issue in the product code inhibits your development, then our support engineers will provide assistance in order to verify any Liferay product defect. When reporting the issue, please provide clear information on the specific API. This includes its expected and actual results, and a simple application or script that demonstrates the issue (if available).
Liferay seeks to resolve issues according to the intended functionality of the product. You may need to change any custom development that leverages unintended functionality.
If intended functionality is reported as an API issue, Subscription Services will explain the functionality using the existing code of the product, offer supporting documentation or a simple example. With API issues the intended functionality is not only defined in the official Admin Guide but in the javadocs and the JSON webservice listings. Please see the Liferay API Documentation knowledge base article for more information.
Contact your Account Executive or Customer Experience Manager to discuss options for getting assistance with your custom development.
Once reported, issues enter the Diagnostic Workflow. During the Diagnostic Workflow, Subscription Services investigates the issue, attempting to reproduce it in order to provide a resolution. Subscription Services must first reproduce any reported issues on an uncustomized product version. Issues that result from product customization are the customer's responsibility. Issues that Subscription Services cannot reproduce will remain in the Diagnostic Workflow, and are resolved on a case-by-case basis. Issues that are beyond Subscription Services' coverage will remain in the Diagnostic Workflow and be resolved on a case-by-case basis. Your Account Executive or Customer Success can assist you with issues not included in Subscription Services.
Liferay seeks to resolve reproducible, unintended defects in uncustomized product versions via patching or configuration changes in accordance with the product service life policy. Patches will change the product's code. Subscription Services can provide documentation for the code changes with the patch. Customers are required to test the patch to ensure it resolves the issue, and report the results to Subscription Services in a timely manner. Prior to installing a patch, customers should backup their system (e.g., code, files, database). To verify that the patch does not conflict with any custom development, customers should install the patch to a non-production environment first. Customers are responsible for any issues with custom development that arise as a result of product defect resolutions.
Emergency Updates, otherwise known as hotfixes, are provided on a case-by-case basis for Liferay components that are deployed on production environments.
Emergency Updates will be made available to customers according to the severity and impact of the product defect, the customer's implementation lifecycle, and the release date of the Fix Pack, Service Pack, or Update in the affected environment. Emergency Updates will be made available in order to resolve catastrophic business critical product defects as determined by Liferay. They will also be made available in order to limit the amount of change made to a live production environment when the production environment is impacted.
Finally, for DXP 7.4 and above as well as Commerce 4.0 and above, Emergency Updates will only be made available for releases which have been issued within 90 days or the last 3 Updates, whichever is greater, as determined by the date the incident was reported to Liferay. For these purposes a release is defined as a new Update released as a bundle or a war file with OSGi dependencies, or a Liferay provided Docker image which includes a new Update.
The original release date of the unique Update number will be used to determine the age of the release and it’s eligibility for Emergency Updates. A new Liferay provided Docker image which contains changes to Liferay scripts, operating systems, or other interoperable technology but does not include a change in the Liferay DXP or Liferay Commerce Update number does not qualify as a new release.
With a desire to increase uptime and availability many customers implement rolling restarts. Rolling restarts allows customers to have near 100% uptime despite server maintenance by selectively shutting down one JVM instance within a cluster, performing the necessary maintenance on that instance, and then restarting that instance to join the cluster again. This process is repeated until all the nodes in a cluster have been updated.
- Liferay seeks to ensure that Liferay DXP is compatible with the industry accepted practice of rolling restarts to modify portal properties, install and uninstall fix packs, install new plugins or modules, update existing plugins and modules, and update the minor java version given that these functions meet the rolling restart requirements.
- Liferay seeks to ensure that Liferay DXP is compatible with the industry accepted practice of rolling restarts to the extent that the product is minimally functional and able to respond to limited requests during the defined maintenance window. Minimal functionality is defined by Liferay product engineers on a case-by-case basis.
- Liferay recommends mitigating the risks of production updates through the rolling restart technique as opposed to hot deployment. However, the feasibility and implementation of the rolling restart technique within a specific environment would be the responsibility of the customer.
- Subscription Services will offer guidance in determining if a Liferay product update meets the rolling restart requirements.
- Successfully performing the rolling restart technique involves the interoperability of multiple third-party technologies. Configuring the third-party technology necessary to perform a rolling restart within a cluster would be the responsibility of the customer.
Rolling Restart Requirements
Any maintenance function performed while utilizing the rolling restart technique must meet the below requirements to be tested as compatible with Liferay DXP.
Fix Pack Installation
Fix pack installation utilizing a rolling restart technique is assured as compatible with Liferay DXP as long as the new fix pack is revertible and there are no non-revertible fix packs in between the currently installed fix pack and the desired fix pack. Fix packs which are or will be included in a service pack contain non-revertible database changes. These fix packs will be identified as non-revertible on the Customer Portal and have Important Changes documentation with them or have been documented in the Rolling Restart - Breaking Changes knowledge base article.
Typically, non-revertible fix packs end with a zero. Not all service packs contain non-revertible fix packs, but many do.
New Plugins or Modules
The deployment of new plugins or modules utilizing the rolling restart technique is assured as compatible with Liferay DXP as long as the plugins or modules do not delete or rename any columns from the database or modify the data in a way that breaks compatibility with existing versions. Any updates which delete tables or break compatibility should be performed while all nodes in a cluster are shut down.
Updating Plugins or Modules
Updating already deployed plugins or modules utilizing the rolling restart technique is assured as compatible with Liferay DXP as long as the plugins or modules do not delete or rename any columns from the database or modify the data in a way that breaks compatibility with the previous version. Any updates which delete tables or break compatibility should be performed while all nodes in a cluster are shut down.
Development techniques exist (e.g., blue-green deployment) which can accommodate database schema changes while utilizing the rolling restart technique. Liferay products will not utilize these development techniques as the technique requires minor changes over time applied specific order and Liferay can not guarantee that product releases will be applied in the proper order.
Blue-green deployment can take place in custom development without impacting the functionality of Liferay Software. Please consult with an Account Executive or Customer Experience Manager to explore options related development assistance.
Java Version Updates
Updating a Java JDK installation utilizing the rolling restart technique is assured as compatible with Liferay DXP given that the version increment is limited to a minor version. Updating the major version of the Java JDK installation utilized by Liferay DXP is not assured as compatible with the rolling restart technique and should be performed while all nodes in a cluster are shut down.