Software Development/ReleaseProcess


Some of us held a meeting on January 29, 2018, where we discussed this over. For all of you which could not attend, your input is still welcome; please escalate it to your coordinator or directly to service.

We’ve mainly converged on the requirements, and are now working on concrete processes and conventions. The general direction can be read from this document, but details herein are now outdated.

We’re currently seeking for approval, and will update this document consequently in February 2018.

-DRAFT- Release Process -DRAFT-

This document is being written while we discuss and engineer the going public with Enigmail 2.0 Beta 1.

The focus is to decouple our internal development pace from other’s development pace. To achieve this, the basic maintenance of previous releases is elongated.

Forward-compatibility has to be back-ported to supported releases. Security and stability issues have to be fixed or worked-around.

Release theory

Every 3 weeks there is a rapid release RR.

Every 7th such release becomes an extended support release ESR.

RR support is discontinued the day the next RR is published.

If an RR is late, the next ESR will match to the 6th, 5th or 4th RR release instead to the 7th, so that the overall pace is recovered. This scheme also allows to exceptionally anticipate an ESR, but this defeats the whole purpose of the release process.

ESR are supported for 27 weeks (i.e. 9 RR cycles, approx. 0.5 year), with an overlap of two RR cycles, i.e. 6 weeks. Thus, 21 weeks after the previous ESR, the next ESR appears, offering 6 weeks time for supported migration.

Release planning

The first (messy) RR is considered being from Monday, January 1, 2018.

The next RR is scheduled for Monday, February 12. It shall be an “ESR candidate” despite being an RR, and will become part of Enigmail 2.0 Beta 1.

The next ESR is regularly scheduled for Monday, March 26, but shall be exceptionally anticipated to March 11. It shall only contain stability fixes and workarounds, but no change of architecture compared to the previous RR (the “ESR candidate”).

The ESR will be maintained for as most half a year.

Changes of architecture are to be merged into the following RR, scheduled for May 7.

Version Numbers

We start counting from 34. The ESR N “is” an RR N.0. There SHOULD be no RR N.8, because this SHOULD become ESR (N+1), aka RR (N+1).0

  • The current (messy) RR is 34.6 (tag with 34RR6)
  • The next RR is 34.7 (tag with 34RR7)
  • The next ESR is 35 (tag with 35ESR)
  • The following RR is 35.1 (tag with 35RR1)

The tag scheme is meant to align alphabetically, chronologically and logically (E comes before R). Fixes are tagged with suffix “-N”.

  • The second fix release of ESR 35 is 35.0.2 (tag with 35ESR-2)
  • The second fix release of RR 35.1 is 35.1.2 (tag with 35RR-2)

Variable workload for support

During 6 weeks of the year (twice for 3 weeks) there are two ESRs and one RR to be maintained.

During 6 weeks of the year (twice for 3 weeks) there are two ESRs and no RR to be maintained.

During 40 weeks of the year (twice for 20 weeks) there is one ESR and one RR to be maintained.

Feature flags

Features are released quickly into the RR and activated by default.

Features are also released into the ESR but disabled by default.

It is recorded, separately for RR and ESR releases, when an user has used a flagged feature.

If an user uses a flagged feature in a RR release, and then falls back to an ESR release, the feature may be disabled if the ESR-shipped feature is still the less mature implementation.

In other words, features must strictly follow a components-based design, and the architecture of the components must land not only in the RR, but also in the the supported ESR.

This release cycle is almost the same as for Firefox, but at double the speed.



  • Enigmail Client
  • pepmda ZIPs for Windows, macOS and Linux
    • JSON Server as Mini Adapter
    • Engine
    • system.db
    • Dependencies: libetpan, libiconv, etc
  • Release Notes
  • Changelog

Prepare the release

To track the creation of the process:

  • A ticket is made in every project, which gives the name for a respective “stable” branch.
    • The ticket is linked to all issues which need to go into the release
    • If we have no access to the repository, clone it.
  • In ENGM, create a master ticket for the release, and make it depend off the project tickets.

Release candidates

Release candidates are built daily.

The binaries are published on the pEp Foundation Software server.