Provide in-context help text on the new release form to explain when to use patch vs minor vs major releases

semver.org:
MAJOR version when you make incompatible API changes (Emphasis added)

Projects, especially larger ones or ones that are a dependency in an ecosystem should think long and hard before they increment the major version. At a minimum, there should be a meta issue discussing the next major version, what goes into it, and what major versions of core you're supporting. (its too bad we cannot link the 'major release' tag to a major issue)

Some type of wording like:
"Bumping the MAJOR version of a release should be done with caution. If a major version is being considered due to upstream compatibility, please review core compatibility best practices (add link that doesn't exist yet)"

-- Which reminds me, I don't think we have a good d10 compatibility guide. We have made some for d10 at Acquia, and Matt and myself have both blogged about it. But nothing is in a concise guide on drupalorg. Thats probably worth expediting as we get into D10 beta.

However, I'm not saying you should never increment a Major because of upstream dependencies, just that its a bit nuanced and most modules should try to be backwards compatible. The default mindset of maintainers should be 'stay on same version' until there is a breaking change that cannot be coded around.

FWIW:
https://github.com/semver/semver/issues/864
https://github.com/semver/semver/issues/14

I'll admit from conversations I've had I'm probably in the minority here on D.O. however contrary to the above blog post I tend to view dropping Drupal Core versions as a change justifying a major bump in most cases and I hope we at least make the tooltip not seem rigid.

A large part of this comes from the fact that semver has evolved to be used by modules that are not api providers.

Why I generally feel dropping core support should be a major? Because for most modules Drupal is generally not just a dependency but rather its a supported operating environment. Its similar in concept to dropping support for a version of PHP (which Drupal is moving towards doing in D10, part of the reason I'm sure I'm in the minority though they are at least coding it so it arguably has become part of the API) or dropping support for an entire operating system. To put this in context of the already provided semver links Dropping Core could break the build process for sites that utilize your module.

There are arguments that since we use Composer as part of the tool-chain we are prevented from breaking by prohibiting downloading a version of the module that is not compatible however recent issues with modules shows that may not be enough at the moment inside the Drupal ecosystem.

Poor dependency management by contrib isn't solved by recommending keeping the same major version, its just delayed. I know we have had two issues lately with modules that are used that contrib may have depended on an open ended dependency, however they will still break eventually when a real API break occurs, and if there is no API break they should not break at all even even if the major is increased unnecessarily. The primary downside with major bumps is that periodically someone needs to come in to contrib and increase the versions they are compatible with to extend their supported range.

For additional consideration:
https://github.com/semver/semver/issues/526

This is the message shown when there are no new branches or tags:

Perhaps we can extend/adapt that message and display it as well when adding a new release.

Somehow the MR is not showing. It's here: https://git.drupalcode.org/project/drupalorg/-/merge_requests/120/diffs

I've abstracted the message and just changed the title when we are adding a new release and there is no error. The message will display like this when adding new releases:

That message is quite large in this context. Maybe we should just show a more-brief message linking to the naming conventions page.

I’m not sure how practical it is to explain what should be a new major/minor/patch version on the add release page itself. If its hard-coded, it'll be harder to update. And it needs to be brief and readable to have a higher chance of being read.

Adapted the code to show a shorter version when adding the release. See below:

Please review and/or suggest text/links for the message.

Addressed the above feedback.

This is now deployed.