Version numbers?

[thomasmatecki]

I ❤️ pipenv.

I am a little curious about the version numbers though. It seems like releases are tagged by year rather than using semver -- that is year.minor.patch rather than major.minor.patch.

I'd like to pin to a version in a CI pipeline, but I can't find it stated anywhere that breaking API changes won't be introduced without a change in the year version. Or perhaps breaking API changes won't ever be introduced?

[matteius]

@thomasmatecki you are totally correct -- right now its the date that is the version number, which creates some problems. You can certainly pin to a version, but it should be an exact date with the way things are now.

Things are constantly evolving in the pipenv codebase and we have some goals to further modernize--in the last release pythonfinder switched from attrs to pydantic, and I have a similar PR out of requirementslib. The requirementslib PR passes the pipenv test suite, but technically there are some behavioral changes to how requirements are parsed there, so despite my best efforts, I wouldn't be surprised if the first release of that will break for someone's edge case.

There is a lot more work to do in requirementslib as well after this as well for example, but that is kind of got me thinking more about semver, because for example the pydantic 2 roadmap has its core being re-written in rust, and the way pipenv vendors creates an interesting challenge for one day getting to pydantic 2 given that requires a system built binary file for pydantic core. Or a different practical example would be making API changes to pipenv. We get requests periodically where well poetry or npm does thing one way, so why does pipenv install re-lock everything, for example. We can make API deprecations and eventual removals, and additions quite well, but changing the actual API of pipenv in a major way cannot reasonably be accomplished on the current versioning strategy.

Or perhaps breaking API changes won't ever be introduced?

We'll do our best, but with the current strategy, in some cases we will intentionally change the API after deprecating part of it. For example --selective-upgrade and --keep-outdated will be removed soon, as the migration path to upgrade and update commands has been established.

[thomasmatecki]

Thanks for the response! Any plans to start using something more like semver?

[matteius]

I think we should consider it -- from what I've gathered, it would be possible to say on some future date we are going to use semvar from now on -- and stop releasing with the date and continue on, so for example we could release 2023.5.20 as a follow-up to the prior release at any time -- and any major version could increment the first number, so we could have a 2024.0.0 later this year if we wanted -- beyond confusing people about if its a date or not for a while, it would work. It would mean we could never go back to using the date though as it was because the version would already be further ahead, so we should make sure to think it through first. There may come a point in the future where we want to do this, right now I think the other thing holding us back is our own organization and knowledge of what is major/minor/trivial.