Making a Platform Release

This page describes the release model for Xfce core components. It further specifies what a Xfce platform release is and what is required in order to do a platform release.

• Core Components
• Timeframe
• Roles
• Roadmap
• Versioning
• Release Phases

A platform release typically includes all Xfce core components. Optionally, it might make sense to as well release various apps, panel-plugins and thunar-plugins after the platform release.

The following components are considered to be Xfce core components and as such have to be part of a platform release https://gitlab.xfce.org/xfce

While the time between the last platform releases was two years, no fixed periodicity to do platform releases is specified. Ruling: “It is finished when it is finished”. If you think it is about time, just communicate that with the other Xfce core developers, elect a release manager, and establish concrete dates and targets for the roadmap.

Whenever a new release is about to be done, the release manager and release manager assistant(s) are elected by the Xfce core developers.

Here is an overview on different roles and their responsibilities:

The main coordinator for platform releases. The release manager does not need to do all the work alone. Instead, as much work as possible should be passed to other Xfce developers. Here is a list of tasks:

• Organization of the release cycle
• Preparation of Roadmap Wiki Page (example)
• Announce deadlines to developers and translators (repeatedly and early enough)
• Organization of development releases
• Tagging of pre1, pre2 component versions
• Doing pre1,pre2 and final platform releases via https://releases.xfce.org/
• Write release announcements for pre1, pre2 and final release (blogposts)
• Coordination of fixes/changes during the release period
• Make sure that https://docs.xfce.org is up-to-date
• Update the Xfce website, including the changelog and the tour
• Take care to get a new default wallpaper

• Help the release manager with his tasks whenever possible
• Take over the job in case the release manager is indisposed for whatever reason

• Do component-specific development releases via xfce-do-release (See as well this Wiki page)
• Write Changelogs and update NEWS files
• Upload the tarball and do component-specific release announcements on https://releases.xfce.org/
• Make sure API documentation is up-to-date

Each platform release should have a dedicated roadmap Wiki page, on which all the release specific details are gathered. The roadmap should at minimum have the following sections:

• Schedule - Concrete dates for the pre-releases and the final release
• Dependencies - The minimum version of libraries we use (Specifically important if some Xfce component needs a cutting edge version of a package)
• Milestone Link - A Link to the Release milestone for quick access
• TODO List - A detailed list to keep track on what has to be done, who is going to do it and what is already finished
• Concrete Versions - Some sub-pages to show the concrete component-versions which are part of a Xfce (pre)-release

Here is the Xfce-4.20 Roadmap as an example

Xfce core components have a master/main branch, on which only development releases are done and multiple stable branches for each platform version, on which only bugfix releases are done.

Development releases are done on the master/main branch. They always use odd minor numbers. E.g. thunar-4.19.4 or libxfce4util-4.17.2. For each development release of a component, the tiny number will be bumped.

Bugfix releases are done on a stable branch. They always use even minor numbers. E.g. thunar-4.18.3 or libxfce4util-4.16.1. For each bugfix release of a component, the tiny number will be bumped.

Ahead of a stable platform release, pre-releases of all core components are done on the master/main branch of each component. A pre-release of a component is pretty much like a development release, the only difference is, that an additional tag, e.g. xfce-4.18pre1 will be added on the branch for that version. If no changes occurred between the latest development release of the component, it is fine to only create the preX tag.

After two or three pre-releases (to be decided by the release manager), the actual platform release is done.

The platform release itself will be done on the master/main branch. E.g. thunar-4.18.0. If a bugfix version is required for that component at some later time, it is required to create a new platform branch, e.g. xfce-4.18 for that component (as well on Transifex) and do the bugfix releases on that branch.

Typically, two pre-releases are done with four weeks between them, in order to allow packagers and early adopters to report possible regressions and blockers. Two weeks after the second pre-release, the actual platform release usually is done. These times proved to work fine, however the release manager can adjust them as desired.

During the planning phase for the release schedule, each maintainer is required to investigate which dependencies to non-Xfce packages are required in which version for the components he/she maintains.

When the release schedule is announced, the core-team should register the minimum dependencies for the platform-release on the roadmap.

Theses minimum dependencies have to be kept for the whole platform release process and are only allowed to be changed in emergency situations, if the release manager and all core developers agree.

With the first pre-release, all core components enter feature freeze, which means from there on only translations and bugfixes are allowed to go into the master/main branch, in order to increase stability.

With the first pre-release, all core components enter string freeze, which means from there on no strings which affect translations may be changed. That allows translators to reach a 100% translation for the platform release.

With the last pre-release, all core components enter code freeze phase, which means from there on no code changes are allowed, unless they are approved by at least two members of the core-team. Such code changes should only be done to fix blocking or release-critical bugs. Translations are still allowed to go in.

Feature and string freeze are initiated by the first pre-release. Code freeze is initiated by the second pre-release and will be kept until the final release has been done.

Release Cycle Example (original odp file is attached)