You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: deprecate include-pre-releases in favor of prerelease (#1515)
* Fix draft release detection to match includePreReleases semantics (#1425)
The `findReleases` function filtered draft releases using
`r.prerelease === includePreReleases`, which is incorrect because
`include-pre-releases` controls whether prereleases count when searching
for the last release, not whether only prerelease drafts should match.
This caused users with `include-pre-releases: true` to never find their
existing non-prerelease drafts (`false === true` is always false),
creating duplicate draft releases on every push.
Fix by using the same filter pattern already used for last release
detection: `(!r.prerelease || includePreReleases)`.
This means:
- `includePreReleases = false` → only match non-prerelease drafts
- `includePreReleases = true` → match any draft (prerelease or not)
Fixes#1425
* Fix test to match suite name: use actual prerelease draft in assertion
The test 'should return prerelease draft when includePreReleases is true'
previously expected a non-prerelease draft (prerelease: false), contradicting
the suite name. Reworked mock data so the test finds a prerelease draft,
matching what the test name describes.
* Match draft release by prerelease status of the release being created
Instead of using includePreReleases (which controls the lastRelease scan)
to filter drafts, use the config's prerelease flag (isPreRelease) to find
the draft whose prerelease status matches what we're about to create.
This correctly solves both #1425 and the original #1385 problem:
- When drafting a stable release, we find the non-prerelease draft
- When drafting a prerelease, we prefer the prerelease draft
- Falls back to a non-prerelease draft if no prerelease draft exists yet
(handles the first prerelease run before the draft is marked)
* feat: deprecate include-pre-releases and document new behavior of prerelease
---------
Co-authored-by: Clément Chanchevrier <[email protected]>
Copy file name to clipboardExpand all lines: README.md
+45-9Lines changed: 45 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -135,12 +135,12 @@ You can configure Release Drafter using the following key in your `.github/relea
135
135
| `exclude-labels` | Optional | Exclude pull requests using labels. Refer to [Exclude Pull Requests](#exclude-pull-requests) to learn more about this option. |
136
136
| `include-labels` | Optional | Include only the specified pull requests using labels. Refer to [Include Pull Requests](#include-pull-requests) to learn more about this option. |
137
137
| `exclude-contributors` | Optional | Exclude specific usernames from the generated `$CONTRIBUTORS` variable. Refer to [Exclude Contributors](#exclude-contributors) to learn more about this option. |
138
-
| `include-pre-releases` | Optional | Include pre releases as "full" releases when drafting release notes. Default: `false`. |
139
138
| `no-contributors-template` | Optional | The template to use for `$CONTRIBUTORS` when there's no contributors to list. Default: `"No contributors"`. |
140
139
| `replacers` | Optional | Search and replace content in the generated changelog body. Refer to [Replacers](#replacers) to learn more about this option. |
141
140
| `sort-by` | Optional | Sort changelog by merged_at or title. Can be one of: `merged_at`, `title`. Default: `merged_at`. |
142
141
| `sort-direction` | Optional | Sort changelog in ascending or descending order. Can be one of: `ascending`, `descending`. Default: `descending`. |
143
-
| `prerelease` | Optional | Mark the draft release as pre-release. Default `false`. |
142
+
| `prerelease` | Optional | Whether to draft a prerelease, with changes since another prerelease (if applicable). Default `false`. |
143
+
| `prerelease-identifier` | Optional | A string indicating an identifier (alpha, beta, rc, etc), to increment the prerelease version. This automatically enables `prerelease` if not already set to `true`. Default `''`. |
144
144
| `latest` | Optional | Mark the release as latest. Only works for published releases. Can be one of: `true`, `false`, `legacy`. Default `true`. |
145
145
| `version-resolver` | Optional | Adjust the `$RESOLVED_VERSION` variable using labels. Refer to [Version Resolver](#version-resolver) to learn more about this |
146
146
| `commitish` | Optional | The release target, i.e. branch or commit it should point to. Default: the ref that release-drafter runs for, e.g. `refs/heads/master` if configured to run on pushes to `master`. |
@@ -344,16 +344,52 @@ autolabeler:
344
344
- '/JIRA-[0-9]{1,4}/'
345
345
```
346
346
347
-
## Prerelease increment
347
+
## Prerelease workflow
348
348
349
-
When creating prerelease (`prerelease: true`), you can add a prerelease identifier to increment the prerelease version number, with the `prerelease-identifier` option. It accept any string, but it's recommended to use [Semantic Versioning](https://semver.org/) prerelease identifiers (alpha, beta, rc, etc).
349
+
Release draft supports working with prereleases. It expects your workflow to be :
350
350
351
-
Using `prerelease-identifier` automatically enable `include-prereleases`.
351
+
- A stable release is published, ex: `v3.5.0`
352
+
- You merge or add meaningful changes your users may want to see, but you are not quite ready for production
353
+
- You publish a prerelease, ex: `v3.5.0-rc.1`
354
+
- You merge more changes
355
+
- You publish another prerelease, ex: `v3.5.0-rc.2`
356
+
- You decide code is ready for production, you publish `v3.5.1` (or another increment based on your changes)
352
357
353
-
```yml
354
-
prerelease-identifier: 'alpha' # will create a prerelease with version number x.x.x-alpha.x
358
+
With release-drafter, you can draft each of these releases and prereleases with the appropriate content using parameter '`prerelease`' and '`prerelease-identifier`' - available as either an input of from the config-file.
Here, both jobs run in parallel every time you add changes to the configured branch.
379
+
380
+
- `update_full_release_draft`will pile-up changes since `v3.5.0` inside a draft for `v3.5.1` (or `v3.6.0` or `v4.0.0`, depending on your config)
381
+
- `update_prerelease_draft` will pile-up changes since the last prerelease in a prerelease-draft. Changes are :
382
+
- if no previous (published) prereleases are found - changes since `v3.5.0` in a draft for `v3.5.0-rc.1` (prerelease-draft)
383
+
- or if `v3.5.0-rc.1` exists (published) already - changes since `v3.5.0-rc.1` in a draft for `v3.5.0-rc.2` (prerelease-draft)
384
+
385
+
Some users like to run `update_prerelease_draft` with `publish: true`, such as prereleases are published immediately without the need for human intervention (or an external automation). Since prereleases are not meant to be stable in the first place, automation may be an acceptable risk for you too.
386
+
387
+
> [!IMPORTANT]
388
+
>
389
+
> - The `include-pre-releases` config was deprecated in `v6.3.0`. See [#1515](https://github.com/release-drafter/release-drafter/pull/1515)
390
+
> - `prerelease-identifier` is not required when `prerelease` is enabled, but your prerelease will be named after / be associated with a tag that is not semver-compliant to actual prereleases.
391
+
> - when specified `prerelease-identifier` enables `prerelease: true`
392
+
357
393
## Projects that don't use Semantic Versioning
358
394
359
395
If your project doesn't follow [Semantic Versioning](https://semver.org) you can still use Release Drafter, but you may want to set the `version-template` option to customize how the `$NEXT_{PATCH,MINOR,MAJOR}_VERSION` environment variables are generated.
@@ -371,8 +407,8 @@ The Release Drafter GitHub Action accepts a number of optional inputs directly i
371
407
| `tag` | The tag name to be associated with the GitHub release that's created or updated. This will override any `tag-template` specified in your `release-drafter.yml` if defined. |
372
408
| `version` | The version to be associated with the GitHub release that's created or updated. This will override any version calculated by the release-drafter. |
373
409
| `publish` | A boolean indicating whether the release being created or updated should be immediately published. This may be useful if the output of a previous workflow step determines that a new version of your project has been (or will be) released, as with [`salsify/action-detect-and-tag-new-version`](https://github.com/salsify/action-detect-and-tag-new-version). |
374
-
| `prerelease` | A boolean indicating whether the release being created or updated is a prerelease. |
375
-
| `prerelease-identifier` | A string indicating an identifier (alpha, beta, rc, etc), to increment the prerelease version. number |
410
+
| `prerelease` | Whether to draft a prerelease, with changes since another prerelease (if applicable). Default `false`. |
411
+
| `prerelease-identifier` | A string indicating an identifier (alpha, beta, rc, etc), to increment the prerelease version. This automatically enables `prerelease` if not already set to `true`. Default `''`. |
376
412
| `latest` | A string indicating whether the release being created or updated should be marked as latest. |
377
413
| `commitish` | A string specifying the target branch for the release being created. |
378
414
| `header` | A string that would be added before the template body. |
0 commit comments