wallabag/RELEASE_PROCESS.md at c526028e22b7c776cf6a8110c1a09ce78795efff

Files

Jeremy Benoist aa029ea73e Automatically create the package after a release

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

2022-06-09 11:30:14 +02:00

1.6 KiB

Raw Blame History

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 in app/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"
        }
    }