Packaging
This page describes at a high level how our packaging systems work.
The documentation for each packaging solution generally lives in README files with the code itself, please consider it authoritative. Short summaries and links to the relevant code are included below.
The Mailpile build systems are geared towards generating nightly or release packages, which are made available to our users on the official Mailpile download page. Our aim is to automate all packaging work, so we can provide timely security- and feature updates to our users.
Our branch policy, as it relates to users and releases is as follows:
Nightly packages are built from the Github master branch.
The master branch is the current "stable-ish" development branch. Technical users should have the expectation that pulling code from master will not break their e-mail, although obviously bugs will be more frequent here than on a release branch.
Major changes that are likely to impact stability will take place on other (hopefully short-lived) branches.
The Github master branch contains no i18n localization files, as translation work currently takes place outside Github (on Transifex).
The Github master branch contains no 3rd party Javascript libraries, those are installed from upstream using bower.
Release packages are built from the Github release branches.
Each point release (e.g. 1.0) will get its own branch. During beta or release candidate development phases, these branches may receive feature updates, but once a release has been announced the only code changes should be bugfixes. Code-related bugfixes should be accompanied by an update to the third version number (1.0.X).
The Github release branches contain i18n localization files and 3rd party Javascript that pertain to that specific release of the app. Translations may be updated and new packages built without incrementing the version number; changes to the Javascript or bundled dependencies (see below) however should be considered code changes and reflected in an increased version.
Code: packages/debian, packages/Dockerfile_debian, Makefile
The Makefile contains a dpkg recipe which builds a Debian package for the currently checked out version of Mailpile (using Docker).
Code: packages/windows-wix
Python scripts use WIX to generate MSI packages for Mailpile. For most of our 3rd party dependencies, we currently import binaries as released by the upstream projects.
(Our previous NSI-based installer scripts are in packages/windows, but will probably be deleted at some point to reduce confusion. They will live on in our git history.)
Code: packages/macos
Scripts download and build 3rd party dependencies from homebrew.
The Windows and Mac packages include our main dependencies, including Python, GnuPG, Tor and OpenSSL. Any or all of these may receive updates at any time, which should eventually be reflected in our packages.
Non-critical updates will be deployed on a 3-month schedule as follows:
- Nightly's and Release will update their dependencies every 3 calendar months, on the 15th day.
- Nightly will update from our upstream sources (projects themselves or packages, such as homebrew)
- If incompatibilities are found in Nightly, rolling forward will be attempted during the first two months of the 3 month period, or reverted to the previous bundle during the last month.
- Release will update to the bundled dependencies used by Nightly in the previous period
Dealing with critical security updates will be a manual procedure and a judgement call (not all security vulnerabilities will impact our use of the underlying tools), which is yet to be defined and documented.