mirror of
https://github.com/wallabag/wallabag.git
synced 2024-12-14 01:15:35 +01:00
aa029ea73e
And then upload it to the created release. One less step during the release process 💪 We are using that GitHub Actions: https://github.com/shogo82148/actions-upload-release-asset I've also: - updated the release script to clone the repo using `https` instead of `git` (otherwise it failed during the build) - use `md5sum` instead of `md5` because the latest isn't available in GitHub Actions
1.6 KiB
1.6 KiB
Definition
A release is mostly a git tag of http://github.com/wallabag/wallabag, following semantic versioning.
Steps to release
During this documentation, we assume the release is $LAST_WALLABAG_RELEASE
(like 2.3.4).
Prepare the release
- 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 a new release on GitHub
- Create the new release on GitHub by targetting the
master
branch or any appropriate branch (for instance backports). - Update nginx config to change the redirect rule for
https://wllbg.org/latest-v2-package
&http://wllbg.org/latest-v2
(they both redirect to the asset of the GitHub release) - Update Dockerfile https://github.com/wallabag/docker (and create a new tag)
- Update wallabag.org 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 🍺!
Target PHP version
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"
}
}