Version policy#

This chapter describes the versions of software that Volto supports and how Volto communicates its releases through its branch policy.

volto-generator compatibility with Volto#

volto-generator is a tool that generates a Volto project. The following table describes the compatibility between versions of volto-generator and Volto.

Generator version

Volto version

9.x

18.x.x

7.x and 8.x

17.x.x

6.x

16.x.x

Plone, Python, and Plone REST API compatibility#

Volto is the default UI for Plone 6. It will work for all released Plone 6 versions.

Volto relies on Plone core (Products.CMFPlone) and Plone REST API. We will always support the latest major Plone release and the version of Plone REST API that ships with it.

The versions of Python that are supported in Volto depend on the version of Plone that you use.

Plone

Python

Volto

6.0

3.8-3.11

16.0 or 17.0

5.2

2.7, 3.6-3.8

15.0

On Plone 6, we recommend using the known good set (KGS) of package versions that are specified in the Plone release.

On Plone 5, Volto is currently tested with the following packages pinned to specific versions, and we recommend using the same versions, which are:

  • plone.restapi 9.2.0

  • plone.rest 3.0.1

  • plone.volto 4.1.0

For the Plone 5 series, the latest released version of Plone 5 is recommended.

Volto should work on older Plone versions as well, since Plone REST API supports Plone back to version 4.3 (including Archetypes).

We do not support or test Plone versions that were released before Volto existed.

Node.js#

Volto runs using Node.js. Volto always supports only LTS versions of Node.js. We recommend using the current LTS version.

  • Node.js 20 LTS: Supported since Volto 17.

  • Node.js 18 LTS: Supported since Volto 17.

  • Node.js 16: No longer supported. It was supported in Volto 14 - 16.

  • Node.js 14: No longer supported. It was supported in Volto 8.8.0 - 16.

  • Node.js 12: No longer supported. It was supported in Volto 4 - 15.

  • Node.js 10: No longer supported. It was supported in Volto 1 - 12.

Supported browsers#

Volto works well with the current version of any modern browser—including Chrome, Firefox, Safari, and Edge—as well as their mobile flavors.

We do not guarantee that outdated browsers, such as Internet Explorer 11, are supported by Volto.

Branch policy#

The Volto team enforces the following branch policy when developers contribute to its core.

Releases of general packages (@plone/generator-volto, @plone/scripts, and so on) are cut from the main branch.

stable and latest

The terms stable and latest mean the same thing in this policy. They refer to the stable and latest released version of Volto. They have no branch names in git.

canary

The term canary refers to the metaphorical canary in a coalmine; if an issue is detected following its release, the damage is limited to only those users who have installed it. It usually includes experimental and breaking features for testing. During the development process, a canary release will be cut from the main branch. When it becomes worthy of a beta or release candidate version, a new numbered branch should be cut, and non-breaking changes must be merged into it.

main

This is the bleeding edge branch in git. It is the branch upon which future development occurs, and from which future releases shall be cut.

When we cut a release candidate, we:

  1. create a new numbered git branch from main, and

  2. cut a release candidate version whose name aligns with the new numbered git branch.

For example, when we cut the release candidate version 16.0.0-rc.1, we created a git branch 16.x.x. We also freeze the release candidate, and stop adding features to it. This allows us to continue development on main, which may include both breaking changes that must not be backported, and bug fixes and feature additions that may be backported but only after the release candidate becomes final.

When opening a pull request, you must open it against main, unless it involves translations. See Branch policy for translations for details.

If the pull request is a feature or a bugfix, and if the release manager deems it useful to the latest version's branch, they may ask you to backport it to that branch.

17.x.x

17.x.x is the current stable and actively developed branch in git. Upon the final release of version 18.0.0, the 17.x.x branch line will be no longer supported. Any new feature will be merged into the main branch, and only backported to and released in older versions, if the Volto Team approves it.

16.x.x

This version of Volto has the same maintenance and support schedule as Plone 6.0. It receives bug fixes and security updates. Any new feature will be merged into the main branch, and only backported to and released in older versions, if the Volto Team approves it.

15.x.x

15.x.x and older branches are no longer supported. If you need a bug fix or security update to any of them, please submit a pull request, and the Volto Team will review it to determine whether it's suitable to merge.

Semantic Versioning#

Volto uses Semantic Versioning to communicate bugfixes, new features, and breaking changes in a release. We use a three-digit dotted version scheme that follows the Breaking-Feature-Bugfix naming convention.

The following sections show examples of the terms and changes in version numbering used to indicate each type of release.

Breaking (or major release)#

A breaking or major release indicates a breaking change that might break an application or third-party add-on that relies on Volto.

4.2.0 -> 5.0.0

For every breaking release, detailed documentation of the breaking changes is in our Upgrade Guide.

Feature#

A feature release indicates that new features have been added to Volto in a non-breaking fashion.

4.2.0 -> 4.3.0

You should expect no breaking changes in a feature release, including new DOM elements. However, the user interface may change. If so, the feature must be under a feature flag and disabled by default, such that it is opt-in.

Bugfix#

A bugfix release indicates one or more bugs in Volto have been fixed.

4.2.0 -> 4.2.1

There should be no breaking changes or changes to the user interface in a bugfix release. It just fixed a bug.