Documentation Overview

The Payara Platform Enterprise Edition project is released each month. Each release incorporates fixes and enhancements from the Payara team and Enterprise-only features.

As of June 2020, The naming strategy of the Payara Platform Enterprise Edition releases is changed.

The general format of the version number is:

Major Version numbers will start from 5 (the current major version of Payara Platform) and only increment by 1 when a new major version (E.g. Payara 6) is released. Fundamental changes (e.g. Javax to Jakarta breaking change) will only be released in Major Versions. There is currently no set cadence for this version change. The change of a major version number is a product management and marketing decision.

Customers should expect changes to their applications and configuration scripts to move to a new Major version.

Minor Version numbers will start from 20 (the year that Payara Enterprise and Community versions diverge) and increment by 1 as required. These version changes will introduce significant features (typically originating from the Product Management process or stabilised and adopted from Community releases).

Features introduced during a minor version change must be backwards compatible with previous minor releases with no intervention required by an operator. Features introduced during a minor version change can only introduce breaking changes as a last resort and with product management approval and appropriate customer messaging.

The Minor Version number will reset to 0 on a Major Version release.

Customers should not expect to change their applications and configuration scripts to move to a minor version unless by choice to take advantage of newly introduced features.

Patch Version numbers will start from 0 and as a minimum increment as required. These version change will introduce bug fixes and patches. The Patch Version number will reset to 0 on a Minor Version release.

Customer specific versions will add an additional 4th level number where the number can reflect something meaningful to the customer e.g. the number of the hotfix. For example if we provide a customer specific hotfix or downported fix for a bug identified with 1234 then the release number for that customer will be 5.20.5.1234

Customers should not expect to change their applications and configuration scripts to move to a patch version.

The Payara Server naming strategy works off of the pre-existing GlassFish naming strategy: Append the year and quarter as the final dot version of the release. For example, for the Payara Server’s release built on GlassFish 4.1, released in quarter 3 of 2015, the version number would be payara-4.1.153.

In the case of updates, we will simply attach an additional point number to the end of the version number described above. For example, if a patch is released for Payara 4.1.152, the version number would be 4.1.152.1. This will be in addition to any extra point releases that Oracle do for GlassFish, so it’s possible for a version number to be something like 4.1.1.152.1!

Some examples of releases made:

We make use of Antora to store and host our technical documentation about Payara Enterprise, as well as general information (such as this document) about the Payara project.

For technical documentation, we only store documentation that we have written, which typically pertains to new or modified features and commands made by us or the community; we do not host GlassFish documentation, nor will we rewrite it for unmodified modules.