Documentation Overview
This page provides some general information about the Payara Platform Community Edition.
Release Strategy
The Payara Platform Community Edition project is released frequently (every 4 to 8 weeks on average). Each release incorporates new features, fixes, and enhancements from the Payara team, GlassFish upstream, and the community.
New Naming Strategy (June 2020)
As of June 2020, The naming strategy of the Payara Platform Community Edition releases is changed.
The general format of the version number is Major Version Number . Year . Release 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. There is currently no set cadence for this version change. The change of a major version number is a product management and marketing decision.
Year will start from 2020 (the year that Payara Enterprise and Community versions diverge) and increment by 1 annually.
Release Number numbers will start from 2 and increment regularly. These version changes will introduce any combination of big features, small enhancements, rewrites, and bug fixes. The Minor Version number will reset to 1 when the Year increments (annually).
There are no backward-compatible requirements for a release number change.
| Release date | Version |
|---|---|
June 2020 |
5.2020.2 |
xxx 2020 |
5.2020.3 |
xxx 2020 |
5.2020.4 |
… |
5.2020.5 |
… |
… |
First release in 2021 |
5.2021.1 |
Second release in 2021 |
5.2021.2 |
… |
5.2021.3 |
… |
… |
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:
Work Strategy
Since Payara Server 4.1.152
We currently have a set strategy to balance receiving the latest Glassfish upstream changes with a need to avoiding making late changes to a release.
Change Freeze
Two to three weeks before a release, we will implement a change freeze. This means that no new features or changes will go into the coming release of Payara Server.
The remaining two to three weeks will be used for finding any bugs brought on by changes and fixes implemented for the coming release. If any bugs are found, these will be corrected before the release; if we can’t fix it before the release date, we will simply revert the change that caused the bug (pending a review).
GlassFish Upstream Cherry-Pick
We aim to do three cherry picks from the GlassFish upstream for each release: just after a release; at the beginning of the penultimate month of the release; and again at the beginning of the final month of the release (before the change freeze). + This to allow us time to find and fix any errors that may be brought in from the GlassFish upstream.
If a bug fix is committed to the GlassFish upstream during our change freeze, we will consider pulling in that solitary commit before the release.
GitHub
The Payara project is hosted on GitHub, allowing us to make use of the various tools GitHub has integrated for managing projects.
GitHub also makes allowing the community access to view and edit the source code very easy and public.
How to Contribute
We make use of the Fork and Pull model. This means that if you want to make any changes, you’ll need to fork the Payara project and make your changes in your own repository. You will then need to create a pull request back into the Payara project’s master branch to merge your changes into the main project.
Before we merge your pull request though, you must read and sign the Individual Contributor License Agreement (CLA) before sending it to us at the address specified on the document, or as an email attachment to cla@payara.org.
Once we’ve received the CLA and checked it for any mistakes, we’ll allow any pull requests you’ve made to start being merged.
In most cases, pull requests will not be merged immediately. This is to allow the Payara team, and other members of the community, to review and deliberate over any of the changes made; we will typically wait 2-3 days before merging any pull requests.
Issue Tracking
We make use of GitHub’s integrated issue tracker to allow the community to create enhancement and bug fix requests. The only requirements to create a bug fix or enhancement request is a GitHub account, and a reproducible bug or idea for an enhancement; you do not need to sign the CLA to create an enhancement or bug fix request. We also provide an Issue Template that can help you describe bug reports or enhancement requests in an easier manner.
Someone on the Payara team, or someone from the community, will then investigate and converse with you about the enhancement request or bug report.
We also attach labels and milestones to issues to help both us, and the community, manage the workflow of these issues.
Documentation
We make use of Antora to store and host our technical documentation about Payara, 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.