Documentation Overview

This page provides some general information about the Payara Platform Enterprise Edition.

Release Strategy

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

New Naming Strategy (June 2020)

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 Number. Minor Version Number. Patch Version Number

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.

Examples

The examples shown below are used only to showcase possible future releases and are not be followed up as a release plan when planning updates on your organization.
  • 5.20.0 = Major Version 5, Minor Version 20, Patch 0

  • 5.20.1 = Major Version 5, Minor Version 20, Patch 1

  • 5.21.2 = Major Version 5, Minor Version 21, Patch 2

  • 6.0.0 = Major Version 6, Minor Version 0, Patch 0

Previous Naming Strategy

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:

2020 Q1 - Payara Server 5.201

2019 Q4 - Payara Server 5.194
2019 Q3 - Payara Server 5.193
2019 Q2 - Payara Server 5.192
2019 Q1 - Payara Server 5.191

2018 Q1 - Payara Server 5.181
2018 Q1 - Payara Server 4.1.2.181

Documentation

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.