Support generating major releases using issue comments

[nicoddemus]

Noticed this while trying to generate release 6.0.0 (#7547)

[Zac-HD]

Haha, there's always something 😂

Looks good to me, and I like that we need a distinct command to do a major release.

[RonnyPfannschmidt]

@nicoddemus while taking a look at that i wonder, if we should make it part of the automation to take the town-crier tags as source of truth for picking the next version

[The-Compiler]

@RonnyPfannschmidt But that's already done for minor/patch releases in that code? How would you distinguish between a minor/major release based on those tags?

[RonnyPfannschmidt]

@The-Compiler we don't use the towncrier data at all to determine the increment, instead we check the branch names/flags

[The-Compiler]

@RonnyPfannschmidt Did you actually look at the code I linked above?

[RonnyPfannschmidt]

i apologize, @The-Compiler i completely messed up when i looked at the file myself and missed that part while looking at other bits

what i'd like to see is to have a auto-trigger for a major release on breaking changes

[The-Compiler]

I'd rather have us decide instead of something automated, for two reasons:

• What if we had no breaking changes after the (manually released) RC? We do happen to have one now, but by pure chance. Of course that could be somehow taken into account as well, but why add a lot of complexity to automate something we do once a year or so?
• What if we have minor breaking changes and deem it okay to release them as part of a minor release? We did that with 5.4.

[RonnyPfannschmidt]

for "back-ported" acceptable breakages, i'd like to see a new category

for breaking changes within a rc process i see 2 paths a) the rc already is a major release so things are fine and b) the the rc was not a major release, the breaking change will require ot "upgrade" to a major release

[nicoddemus]

@RonnyPfannschmidt @The-Compiler

I think I lean with @The-Compiler here because of the points he's made, plus we always review the changelog for major/minor releases, so any mistakes can be caught at that point. For that reason I think explicitly asking a "major" release seems fine, and I think the same idea can be made for release candidates ("please prepare release candidate", which I almost did in this PR, but decided to keep it simple and do that afterwards).

I think the discussion is worth having, but perhaps in a separate issue? After all which is being discussed here will be used effectively only by the time to release 7.0 comes around.

[The-Compiler]

Taking the freedom to merge this now, as we seem to be +3 vs. -1 regarding the way how a major release should be determined. I don't think this should be blocking us from a 6.0.

[RonnyPfannschmidt]

I can go with Bruno's reasoning, thanks for elaborating

[nicoddemus]

I can go with Bruno's reasoning, thanks for elaborating

OK thanks @RonnyPfannschmidt. Created #7551 as follow up. 👍

[The-Compiler]

Looks like the CI failed on master after this was merged. Looks like a GitHub Actions bug though, as it just hanged for 45min after installing dependencies... 😕

[nicoddemus]

Probably, the script is not really part of a normal CI run at all.