This article describes Liferay's policy regarding versions.
Version Number Explanation #
Versions consist of a three digit number in the form of major.minor.maintenance, e.g. 6.0.2 (major version 6, minor version 0, maintenance version 2.)
A change in the third digit (e.g, 6.0.2 to 6.0.3) is a maintenance update (AKA Service Pack.) This means that:
- Each maintenance update provides higher security / reliability.
- Customizations are generally safe but we recommend doing a review.
- No new features are included (although the first few maintenance releases can contain some changes to existing features based on the feedback received). There were some exceptions to this rule in some 5.2 maintenance releases but we've decided to be much more strict for Liferay 6.
- These rules are relaxed when the major release is still in beta quality.
A change to the second digit (e.g., 6.0 to 6.1) is a minor release. This means that:
- This will include new features plus bug fixes from prior releases.
- No changes will be made to API's without deprecation process, architectural configuration or schema changes.
- Customizations may be affected when installing. Customers should leverage the upgrade tools and documentation.
A change in the first digit (e.g., 6.x to 7.x) is a major release. This means that:
- This will include major changes in functionality or add high-demand functionality
- This may include architectural changes, changes to API's (as part of deprecation process) and may change internal schema
Release process #
Starting with Liferay 6 each version will have a surname that specifies the expected quality of that release. The third version number is usually hidden, but it's still visible through the logs and administration UIs. Here is the evolution of versions:
- Preview and Beta (6 Preview 1, 6 Beta 1, 6 Beta 2, ...): There can be zero or more of these types within each major release. These releases are meant for testing and to provide us feedback through the beta testing category in the forums. There can be changes in features between beta releases but in general they won't be major.
- Release Candidates (6 RC1, 6 RC2): There can be 0, 1 or more of these right after the beta releases. This are more stable and are meant for those that prefer to wait a little to test the release.
- General Availability (6 GA1, 6 GA2, ....): There can be 1 or more of these releases. A General Availability version is released when our engineering team and the QA team based on our own testing and the feedback from the beta testers decide that the release has good quality and can be of general use for the community. Of course this doesn't mean that it's bug free so we keep an eye on the community since at this point many more people start using the version and find new bugs (usually minor). When this happens we fix the issues and release a new GA version. Several GA versions may be made available until the engineering team moves towards releasing an EE release.
- Service Packs (6 SP1, 6 SP2, ...): These are maintenance releases will keep coming out for 4 years after the original release date. These releases are only available to customers who have an update service that comes with every Enterprise Edition. To ensure this we have a team dedicated to keep testing and doing corrective improvements to this release to ensure the highest quality. All fixes done in the service packs are also done in svn and will be part also of the next minor or major release. This ensures that all the community benefits from the fact that we can have more people working on QA as more customers buy our Enterprise Edition services.
The following diagram represents this in a graphic form:
Here are some recommendations to help you decide which version to use
- You are very welcome to use any preview, beta or release candidate version. In fact that's why they exist so that as many people as possible start using it and provide us their feedback. However, we do not recommend using beta releases in production or even during development if you have tight deadlines (since you may find road blocks).
You should always update to the latest maintainance release available for the minor or major version you are using. This means that at the time of writing you should be using Liferay 6 GA 2, but if we later decide to release GA 3, our recommendation is that you switch to it since it includes fixes for other bugs found by other Liferay users.
- Updating to a new maintenance release should be a process that requires little effort from the first GA forward. That is, you should be able to upgrade from Liferay 6 GA 1 to any future Liferay 6 GA or any Liferay 6 SP within hours or days in the worst case scenarios.
- To ensure that the updates are as easy as possible (and also ease upgrades to new minor or major versions) use the best development practices when extending Liferay. I'll write a blog post (or maybe a whitepaper) with more details but at the very least you should use plugins instead of the extension environment (or ext plugin) whenever possible. And always use APIs that are meant to be public (specially when using ext). Also avoid overriding JSPs that have a lot of logic or keep a very tight control of them (and review them when updating for changes to the originals).
- Plugins that work in any GA or SP version will work in any later maintenance version. That is, a plugin developed for Liferay 6 GA1 will also work in Liferay 6 GA or Liferay 6 SP3, or .... This is something that we've tried to guarantee in the past but hasn't always been possible. Starting with Liferay 6 we have a testing process in place to make sure this is really guaranteed.
- Consider investing in the updates and support services of the Enterprise Edition. This will benefit you two-fold, first because you'll be getting quality services that will add value to your Liferay installation and second because it will help evolve the product with new features that you will be able to benefit from.