Skip to content

Latest commit

 

History

History
76 lines (70 loc) · 4.16 KB

RELEASING.md

File metadata and controls

76 lines (70 loc) · 4.16 KB

Clash's release process

Clash actively deploys to one platform: Hackage, a source distribution platform for Haskell applications.

Development happens on the master branch. Released versions live in 1.0, 1.2, etc. Changes made to these branches automatically get published every night. This is achieved through GitLab Pipeline Schedules. (You need admin access to see that page.) At the time of writing it gets triggered on master and 1.6. A release candidate gets pushed out with the version numbers in the various cabal files. Candidates can be previewed on a special Hackage page.

Branches overview

  • master: development branch

    • Only members of the devops team can merge to it

  • [0-9].[0-9]: release branches

    • Only members of the devops team can merge to it
    • Warning: matches 1.0, 1.2, but NOT 1.22 (GitHub limitation).

Releasing a new version major version (1.x)

  1. Change version numbers in:
  • clash-prelude/clash-prelude.cabal
  • clash-prelude-hedgehog/clash-prelude-hedgehog.cabal
  • clash-lib/clash-lib.cabal
  • clash-lib-hedgehog/clash-lib-hedgehog.cabal
  • clash-ghc/clash-ghc.cabal
  • clash-cores/clash-cores.cabal
  • docs/conf.py
  1. Update the CHANGELOG (see changelog/README.md). Each entry should normally end with a link to a PR or issue. The script changelog/blame_pr.py will tell you for a single file which PR('s) introduced it.
  2. Add a new pull_request_rule for backports to .mergify.yml for the branch you will create.
  3. Create a release branch named after the major version of Clash you're trying to release. For example, if you're planning on releasing Clash 1.6.0, create a branch called 1.6.
  4. Repeat step (1) in the new release branch.
  5. Ask someone with admin permissions on GitLab to create a new nightly schedule and trigger a test release build on GitLab CI. The new schedule should be the same as the old one, but targeting the new release branch. Verify that the Hackage release deploys well, and preview the release. Preview on Hackage
  6. Write release notes for: Twitter, LinkedIn, and clash-lang.org.
  7. Create a release on GitHub's new release page
  8. After the release is on Hackage: run changelog/comment-gh.py and execute the commands it lists. This will inform users subscribed to specific issues that a fix for their issue is now in a released version.
  9. Update the starter projects
  10. Update these docs if anything is missing :-)
  11. Enjoy!

Releasing a new version minor version (1.x.x)

  1. Change version numbers in:
  • clash-prelude/clash-prelude.cabal
  • clash-prelude-hedgehog/clash-prelude-hedgehog.cabal
  • clash-lib/clash-lib.cabal
  • clash-lib-hedgehog/clash-lib-hedgehog.cabal
  • clash-ghc/clash-ghc.cabal
  • clash-cores/clash-cores.cabal
  • docs/conf.py
  1. Update the CHANGELOG (see changelog/README.md). Each entry should normally end with a link to a PR or issue. The script changelog/blame_pr.py will tell you for a single file which PR('s) introduced it.
  2. Ask someone with admin permissions on GitLab to trigger a nightly schedule, or simply wait a day. Verify that the Hackage release deploys well, and preview the release. Preview on Hackage
  3. Create a release on GitHub's new release page
  4. Update the starter projects
  5. Cherry-pick commit made in (2) to master
  6. After the release is on Hackage: run changelog/comment-gh.py and execute the commands it lists. This will inform users subscribed to specific issues that a fix for their issue is now in a released version.
  7. Update these docs if anything is missing :-)
  8. Enjoy!