wallabag/RELEASE_PROCESS.md
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

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"
        }
    }