|
1 | 1 | Releasing |
2 | 2 | ========= |
3 | 3 |
|
4 | | -The deployment process of `cucumber-jvm-scala` is based on |
5 | | -[Deploying to OSSRH with Apache Maven](http://central.sonatype.org/pages/apache-maven.html#deploying-to-ossrh-with-apache-maven-introduction). |
6 | | - |
7 | | -## Check [](https://travis-ci.org/cucumber/cucumber-jvm-scala) ## |
8 | | - |
9 | | -Is the build passing? |
10 | | - |
11 | | -``` |
12 | | -git checkout main |
13 | | -sbt clean +test |
14 | | -``` |
15 | | - |
16 | | -Also check if you can upgrade any dependencies: |
17 | | -- check RenovateBot open Merge Requests on Github |
18 | | - |
19 | | -## Decide what the next version should be ## |
20 | | - |
21 | | -Versions follow [Semantic Versioning](https://semver.org/spec/v2.0.0.html). To sum it up, it depends on what's changed (see `CHANGELOG.md`). Given a version number MAJOR.MINOR.PATCH: |
22 | | - |
23 | | -* Bump `MAJOR` when you make incompatible API changes: |
24 | | - * There are `Removed` entries, or `Changed` entries breaking compatibility |
25 | | - * A cucumber library dependency upgrade was major |
26 | | -* Bump `MINOR` when you add functionality in a backwards compatible manner: |
27 | | - * There are `Added` entries, `Changed` entries preserving compatibility, or |
28 | | - `Deprecated` entries |
29 | | -* Bump `PATCH` when you make backwards compatible bug fixes: |
30 | | - * There are `Fixed` entries |
31 | | - |
32 | | -Display future version by running: |
33 | | - |
34 | | -``` |
35 | | -make version |
36 | | -``` |
37 | | - |
38 | | -Check if branch name and version are as expected. To change version, update the _version.sbt_ file: |
39 | | - |
40 | | -``` |
41 | | -version in ThisBuild := "6.8.3-SNAPSHOT" |
42 | | -``` |
43 | | - |
44 | | -## Secrets ## |
45 | | - |
46 | | -Secrets are required to make releases. Members of the core team can install |
47 | | -keybase and join the `cucumberbdd` team to access these secrets. |
48 | | - |
49 | | -During the release process, secrets are fetched from keybase and used to sign |
50 | | -and upload the maven artifacts. |
51 | | - |
52 | | -## Make the release ## |
53 | | - |
54 | | -Check if branch name and version are as expected: |
55 | | - |
56 | | -``` |
57 | | -make version |
58 | | -``` |
59 | | - |
60 | | -Do the release: |
61 | | - |
62 | | -``` |
63 | | -make release |
64 | | -``` |
65 | | - |
66 | | -All done! Hurray! |
| 4 | +Releases are automated via a [GitHub Actions workflow](./.github/workflows/release-sbt.yml). Only people with permission to push to `release/*` branches can make releases. |
| 5 | + |
| 6 | +See [Cucumber release process](https://github.com/cucumber/.github/blob/main/RELEASING.md) for the whole process. |
| 7 | + |
| 8 | +## Preparation |
| 9 | + |
| 10 | +1. Decide what the next version should be according to semver |
| 11 | + ```bash |
| 12 | + export $next_release=<version> # <- insert version number here |
| 13 | + ``` |
| 14 | +1. Update the `version.sbt` file with version to release: |
| 15 | + ```bash |
| 16 | + echo "ThisBuild / version := \"$next_release\"" > version.sbt |
| 17 | + ``` |
| 18 | +1. Update the CHANGELOG and documentation, commit and push: |
| 19 | + ```bash |
| 20 | + make prepare-release |
| 21 | + ``` |
| 22 | + |
| 23 | +## Release |
| 24 | + |
| 25 | +1. Push to a new `release/*` branch to trigger the `release-*` workflows |
| 26 | + ```bash |
| 27 | + git push origin main:release/v$next_release |
| 28 | + ``` |
| 29 | +1. Wait until the `release-*` workflows in GitHub Actions have passed |
| 30 | +1. In `version.sbt`, bump the **patch** version and append `-SNAPSHOT` (e.g. `1.2.4-SNAPSHOT`) and commit/push |
| 31 | +1. Announce the release |
| 32 | + * in the `#newsletter` Slack channel |
| 33 | + * on the `@cucumberbdd` Twitter account |
| 34 | + * write a blog post |
0 commit comments