I personally prefer Semver. I think it's reasonable, simple, and makes sense. But as a good Haskell citizen, I'd like to be PVP-compliant as well. Here is a bit of a graphic showing how the two systems are almost the same:
PVP: A . B . C . ...
Semver: Major . Minor . Patch
^ ^ ^
| | |
| | ` increment for other changes
| |
| ` increment on non-breaking change
|
` increment on breaking change
Basically, PVP's A
is useless from a compatibility standpoint. It's just a bystander in the "increment A.B
for breaking changes" rule. So I just set it to 0
and never change it. The remaining 3 components then follow Semver.
So for any of my packages, you can interpret versions as: 0.Major.Minor.Patch
It contains the leading
A.
.Regardless of how I'm bringing a SemVer perspective, or being PVP compliant, the version is the version: whatever string comes after
version:
in mypackage.yaml
. Intention or perspective doesn't matter once it's been set for the package.That's a nice process. You're sort of leaning into them being two different things and using SemVer generally, but "converting" to a PVP version specifically for Hackage. This is different than my goal, which is to just have one versioning scheme that makes sense through both lenses.
I agree it's probably not great to intentionally not be PVP-compliant in any pre
0.1.0.0
versions. I'll continue to consider it and probably do it less often, only in extremely not-used packages. For anything with users that may be impacted I would probably just push0.1.0.0
sooner and follow PVP thereafter. I'm like you in that I work in the open and publish immediately, regardless of polish.