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.
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.
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.
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:
composer upon this new branchgit add --force composer.lockgit pushso the branch is tested on travisWe are done.
Infine, do we have to remove the pushed release branch?