A release is mostly a git tag of http://github.com/wallabag/wallabag, following semantic versioning.
During this documentation, we assume the release is $LAST_WALLABAG_RELEASE
(like 2.3.4).
- Update these files with new information
app/config/wallabag.yml
(wallabag_core.version
)CHANGELOG.md
- Create a PR named "Prepare $LAST_WALLABAG_RELEASE release".
- Wait for test to be ok, merge it.
- Create the new release on GitHub by targetting the
master
branch or any appropriate branch (for instance backports). - Update website to change the redirect rule for
/latest-v2-package
&/latest-v2
. They both should redirect to the asset of the GitHub release. - Update Dockerfile https://github.com/wallabag/docker (and create a new tag)
- Update website website (downloads, MD5 sum, releases and new blog post)
- Put the next patch version suffixed with
-dev
inapp/config/wallabag.yml
(wallabag_core.version
) - Drink a 🍺!
composer.lock
is always built for a particular version, by default the one it is generated (with composer update
).
If the PHP version used to generate the .lock isn't a widely available one (like PHP 8), a more common one should
be locally specified in composer.lock
:
"config": {
"platform": {
"php": "7.4.29",
"ext-something": "4.0"
}
}