Wallabag release process doc

release_process.md

Definition

A release is mostly a git tag of http://github.com/wallabag/wallabag, following semantic versioning. The last release at the time of writing is 2.0.0-alpha.2, from the v2 branch.

Creating a release tag

In order to create a release tag, it is usually easier to create a release branch:

$(v2) git checkout -b release-2.0.0`

The branch does not have to be pushed. It may nonetheless make sense to push it so that Travis runs of it, or to collaborate with others on the release.

From this branch, the release can be finetuned before tagging. Even if the release branch is never pushed, or deleted, the git commits will still be valid.

(extra) contents of the tag

composer.lock

A release branch must contain a composer.lock file. It sets which dependencies were available at the time a release was done, making it easier to fix issues after the release. It also speeds up composer install on stable versions a LOT, by skipping the dependencies resolution part.

Since composer.lock is ignored by default, either it must be removed from .gitignore in the release branch, or it must be added using git add --force composer.lock.

Target PHP version

composer.lock is always built for a particular version, by default the one it is generated (with composer update).

Fortunately, it is possible to force a particular target version using composer.json.

+1 for push the branch anyway, just in case that it could failed on travis.

As far as I understand:

1. be up to date on the main branch
2. create a new branch named against the new tag
3. composer up on this new branch
4. git add --force composer.lock
5. git push so the branch is tested on travis
6. tag the version on this new branch

We are done.
Infine, do we have to remove the pushed release branch?