Plans to switch to semver versioning in 2024

[matteius]

I think there are some possible benefits we can try to achieve by moving away from date based versioning in pipenv to semver.

1. Try to identify breaking changes in the the review process and let that influence the versioning number
2. Be able to release more than one version in a day (ie: bugfix release) in a sane manner.

To do so we don't have to diverge far from what we are doing, its just the major version will start out 2024 but could increment beyond that in a single year. The minor and patch versions would no longer correlate to the month/date of the release but would go up sequentially, meaning a newer release should always be ordered higher in the chain.

Now is the time to share thoughts and feedback about this -- my plan would be to ensure the invoke release.release command no longer generates release numbers based on datetime, and instead it would have to be supplied when creating a new release.

[oz123]

I like this idea very much. It will (hopefully) convey changes to our users in a more transparent way...

[matteius]

We just cut our first semver release -- a patch release 2023.11.17 -- It skipped 16 because the script logic wasn't quite prefected (we bumped to 2023.11.16-dev I deleted the -dev flag, and then ran release.release input patch and we got out 2023.11.17. I pushed a couple fixes to the build process (Sphinx upgrade and to add back the --dev bump step for now since CI calls that after pypi release).