Proposal to change default release value for Release Drafter

[smenzer]

Type of issue

Proposal

Description

With the addition of Release Drafter (#5954), we now can use particular labels to indicate what the next version of Prebid should be. The way RD works is it will increment using the "highest" version label in any PRs for the release - major (1.x.x) trumps minor (x.1.x) trumps patch (x.x.1). For example, if we are at version 1.5.0 today, we could have a new release with only patch-labeled PRs and the next version would be 1.5.1; but if any single PR had the minor label, it would increment the minor value and the release version would be 1.6.0.

This is nice, but doesn't exactly align to how we do Prebid.js releases today. Today, every week we do a new release and increment the minor version. In rare cases, there is an urgent bug that needs to be corrected and we'll do an off-cycle patch release. Every so often, a breaking change release of Prebid will be done and the major version will be incremented. Both the patch release and the major release are typically handled very manually and PRs are carefully selected to go in them.

Proposal

Since we don't really need Release Drafter to handle the version numbers for us (we almost always increment the minor version), I propose we eliminate the need to add the version labels to each PR. Instead, we could change the "default" version to minor (in https://github.com/prebid/Prebid.js/blob/master/.github/release-drafter.yml#L25 change to default: minor). By doing this, every release will be treated as a minor release and we can avoid setting extra labels (which has caused a bit of confusion to-date). When a patch or major version need to be released, we simply manually set the version number like we would have pre-Release Drafter.

cc @GLStephen @gglas

[gglas]

@smenzer did we land on something here? I remember discussing in a weekly and we just chatted on issue review and feel pretty good about it...was there any debate? If not, shall we assign for implementation?

[smenzer]

I think we landed on what I mention above in the proposal...then we don't have to worry about adding those labels, and only need to add the feature/bug/maintenance labels

[ChrisHuie]

Closing with pr submission #6827