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).

[matteius]

Just wanted to call out that at one point we had talked releasing pipenv 3000 -- that basically just happened, but its pipenv 2024.0.0

Nate Prewitt called out kind of in the final hour that we might not want to go straight to 3000 and that got me thinking. Still its semver, but we are at major version 2024 now.

[edmorley]

Yeah but bumping to v2024 doesn't really help - since it now matches the current year, so gives the false impression pipenv is still using calver (for anyone who doesn't follow along with every GitHub discussion or read the changelog in detail; which will be most end-users). Using v3000 would have avoided that issue.