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).
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 that pertain to that specific release of the code. Translations may be updated and new packages built without incrementing the version number.
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.