Release Process

Branches

There are three release-related branches: master, staging and release.

Master branch

The master branch is the development branch where the latest updates will be applied.

Staging branch

The staging branch is used for preparing and testing releases.

Release branch

The release branch is used for releasing new updates for general use. Every commit in this branch is automatically released to real users, which is why not everybody with write access to the repository can push to this branch.

Builds / channels

• The release build uses flattr.com servers and the release branch mentioned above.
• The staging build uses smickr.net servers and the staging branch mentioned above.
• The development build uses smickr.net servers and the master branch mentioned above. This is used for testing.
• The usertesting build uses smickr.net servers and the master branch mentioned above. This was meant for user testing, but we have so far not needed it and are unsure if we are going to need it.

Release process

Whenever we want to make a release, we perform the following steps in order:

1. Update the version in src/manifest.json and land that change in master.
2. Merge master into staging.
3. Test the staging build, ideally for a full week. During this time, only bug fixes can be landed in staging, while arbitrary changes can continue to be landed in master. Bug fixes should be landed in both master and staging until the release is made.
4. Merge staging into release.
5. Tag the release branch HEAD as "v" + version, e.g. v0.1.0.

Hot fixes

Hot fixes should follow the same process as regular releases, albeit presumably with less testing time. If a release is already in progress, we should wait for that instead of starting a hot fix release in parallel.