Introduce flag to consider pre-release version when drafting new release

[rchristilaw]

The changes in #1240, which removed the latest pre-release version from consideration when drafting a new release has introduced problems for my worklow. In my workflow use case, I create a new pre-release which does not get released right away. This is resulting in the new draft release being named the same as the pending pre-release.

Example:
v1.2 (Latest Released Version)
v1.3 (Pre-release pending release)

While v1.3 still has not been released, a new draft release is created, but since v1.2 is the latest release, and v1.3 prerelease is now ignored, a new draft release named v1.3 is created, rather than a version v1.4.

The ask is that a config flag is created which will allow for consideration of pre-releases when resolving a new version, and allows release-drafter to function as it did prior to Release v5.22.

[tcyran]

We are having exact same issue as @rchristilaw

From logical point of view of how action this behaviour is simply wrong. There should be a flag which consider ignoring pre-release and if such flag is enabled there should be also option to automatically remove conflicting pre-release version to avoid action to fail.

Also I would consider if such change should be considered as minor release, as many ppl could build their workflow base on previous behavior. So IMHO it's major release as it's breaking change :)

[vdubovets]

+1, We've faced the same issue. It breaks our existing logic as our deployment flow depends on prerelease label.
Having the config flag that adds prereleases into the filter would be nice.
Thanks!

[ranger-ross]

+1, This broke my team's workflow as well.
I believe this should have been a breaking change due to the behavior, or made this behavior opt-in.

For those who's workflows are now broken, you can force the previous version with the following code in you GitHub Action

uses: release-drafter/release-drafter@v5.21.1

This fixes the issue in my project

[robbinjanssen]

I've created a pull request #1302 where you can config this behaviour. The default functionality will be the same as introduced by #1240