Introduction
As of November 2025, we have adopted an updated version control schema for all our products, including Gravity Forms core and add-ons. This article provides an overview of our version numbers and their relationship to the various types of updates we offer, as well as a methodology that allows our users to determine the basic impact of an update by knowing just the version number.
Scope
Inspired by Semantic Versioning (but diverging from its precise specification), our version numbers are intended to provide a declaration of the type of content in the package. The intent here is to enable our customers to clearly identify the implications of a version update even before they have reviewed the changelog.
This methodology is being adopted across all our packages from November 2025 onwards. Previously released version numbers have not been altered.
This is a change to our previous version numbering approach, where major versions did not carry any stated commitment about the content contained within, and add-ons were updated differently.
Version Numbering
Nomenclature
Most releases will follow the following nomenclature:
MAJOR.MINOR.PATCH
- where each of the arguments above is an integer with no leading zeros.
- where any increase in one number means the numbers following restart at 0. For example: Release 1.2.3 could be followed by 1.2.4, 1.3.0, or 2.0.0
Version Number Meaning
Each release implies a specific type of update which can be identified by the digit that was incremented.
- A MAJOR version number will be incremented when we make changes that may break existing functionality. We strive for backwards compatibility, but with the very long life of Gravity Forms, sometimes internal changes are necessary that may break older functionality. In most cases, this is changing an integration point such as removing or changing the behavior of a filter. Major versions will not auto-update and require a manual action to update.
- A MINOR version number increase will be made when we add functionality in a backward-compatible manner. This may include the roll-up and “full” release of previous hotfix releases. They can be installed via automatic background updates.
- A PATCH version number will increase with every release of backward-compatible bug fixes. This may include new fixes and/or the roll-up and “full” release of previous hotfix releases. They can be installed via automatic background updates.
For a full description of these update types and where to find the settings for automatic background updates, check this article, which discusses the importance of updates.
Additional Suffixes: Hotfix
A hotfix will include a fourth integer after the most recently released version number.
MAJOR.MINOR.PATCH.HOTFIX
A hotfix is a version with a specific bug fix or a critical security fix for confirmation. Hot-fixes are not made available to the auto-update system, but are made available for download or may be provided directly to affected customers via our Support channels. Once a hotfix is confirmed, it will be released in a “roll-up”. See below.
The suffix for a hotfix is appended to the version that the
Example: Gravity Forms 2.9.12.1 would be a hotfix released to resolve an issue found in Gravity Forms 2.9.12.
Rolling Up the Hotfix
The fourth hotfix digit will go away when the fix or changes it contains are confirmed as effective and “rolled up” into the next Patch, Minor, or Major release. Once rolled up, the changelog entries for preceding hotfixes are also combined into a single entry for the Patch release.
Example:
Gravity Forms 2.8.19.1 & Gravity Forms 2.8.19.2 could be rolled up into Gravity Forms 2.8.20 (which may also include previously unpublished fixes). They could also be rolled up into Gravity Forms 2.9, which includes previously released hotfixes, previously unpublished fixes, and some new (backwards-compatible) functionality.
Additional Suffixes: Beta and Release Candidates
MAJOR.MINOR.PATCH-{identifier}
A pre-release or beta is generally a sneak preview of upcoming new functionality that is made available for customer sandbox testing. To identify a pre-release, a suffix will be identified as a dash (-) followed by one or more alphanumeric strings (with optional periods) after the MINOR or MAJOR identifier.
Pre-releases and Betas are provided outside the normal distribution and must be manually downloaded and installed. No auto-updating is provided for pre-release or beta versions. If you update a pre-release or beta version, you will be upgraded to the latest stable version.
In this case, the preceding digits identify the release that the pre-release or beta update is aiming towards.
Example: The first release candidate or beta of Salesforce Add-On might be Salesforce 1.0.0-rc.1 or Salesforce 1.0.0-beta.1.
Summary
This table summarizes the above information. It only applies to updates and versions released after the adoption of this version numbering system.
| Release Type Sample Version* | Contains | Available to Auto-Update? |
|---|---|---|
| Major Gravity Forms 3.0 | New functionality or fixes. Contains changes that may alter or break existing functionality. | No |
| Minor Stripe 6.1.0 | New functionality and or fixes that are all backwards compatible. | Yes |
| Patch Partial Entries 1.8.2 | Fixes that are backwards compatible. | Yes |
| Hotfix Breeze 1.8.1.1 | A fix in an interim release to address a specific issue. Will be rolled up into the next non-hotfix release. | No |
| Beta reCAPTCHA 3.0.0-beta1 | Pre-release for customer testing during development of a major or minor release. | No |
| Release Candidate Quiz 4.0.0-rc1 | Pre-release that signals the approaching end of development for a minor or major release. Further release candidates may follow. | No |
(*) These are samples only and may not correspond to actual releases.