Update release script to enforce semver going forward in 2024

[matteius]

RE: #6014

The issue

Semver for 2024 -- I anticipate we will have a release 2024.1.1 and then we can follow the semver patterns. Also simplify the release script some -- I don't think we ever use the local build to pypi thing, lets just rely on the CI to do it.

https://github.com/pypa/pipenv/blob/master/peeps/PEEP-000.md

• Associated issue
• A news fragment in the news/ directory to describe this fix with the extension .bugfix.rst, .feature.rst, .behavior.rst, .doc.rst. .vendor.rst. or .trivial.rst (this will appear in the release changelog). Use semantic line breaks and name the file after the issue number or the PR #.

[deivid-rodriguez]

This seems nice! 💪

Does this also mean that there will be a major yearly release that will include any potential breaking changes merged during the year?

[matteius]

@deivid-rodriguez I don't think we are as organized or have enough time to make guarantee like only one major release a year kind of thing. I think we will have to evaluate what is included in the release and understand the implications as we merge things -- so 2024 could get up to 2027.1.1 -- we just don't know yet.

[deivid-rodriguez]

Oh, I see, so the major version will no longer necessarily be linked to the current year, but will just be a standard major version, just a very high one 😅. One major per year seemed neat, but I would understand if you don't want to delay major changes that long.

[mungojam]

I'd start at 3001.0.0 or something similar, otherwise it could look like a stale project after a few years if you don't do many releases each year (in 2026 it might still be on version 2024.x.y)