Versioning Haskell: Semver <> PVP

semver-pvp.md

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

Yeah, that's quite annoying.

The thing is I like to have automated deployments for every commits I push to my default branch, and I make my work available as soon as possible, even if it is not "stable" yet. I believe it is an invaluable way to get good and early feedback about the API. It also save me from asking myself "when do I release? should I release?". I always release everything, every commit. So the only remaining choice I have to make is: "what is the stability I want to communicate to my users".

Sadly that doesn't seem possible with PVP :-/

I depart from PVP here and I will not hold myself to compatibility bumps in releases until I reach a 0.1.0.0 version, which I consider "1.0" in SemVer's parlance.

That's an understandable point of view, but it is important to realize that a breaking change when going from 0.0.1.0 to 0.0.2.0 is technically not PVP compliant. So I am not sure weather I'd allow myself to follow the same pattern :-(.

I guess the only thing I can do is follow the 0.MAJOR.MINOR.PATCH convention, and publish everything as stable, even if it is not... I guess that it is not possible to do better in Haskell. Quite a shame.

The examples they give are good ones, that I have and would use this component for myself

I am not sure how good they are. To me they sound like an excuse to not change for semver. At least from my point of view they are not good enough to justify the usage of a language specific versioning scheme (that does not support pre-release concept) rather than following semver.

And actually the very fact that they give multiple different usages of the first major member is a sign that is is not good. It means it will always have different meaning depending on the library and it is open to interpretation. The goal of any versioning specification is to eliminate room for subjective interpretation.

Thanks for taking the time to respond with so much details and sources.

Last question, in your git repository, do you create tag after semver or PVP version? In other words, do your tags contain the leading 0. ?

Okay, I think I know what I will do.

I follow semantic versioning just the "normal" way. And my automated release process only has to be slightly more complex than it usually is.

For each release:

• Generate the change log, create the git tag (semver style), and github release (as usual)
• If, and only if, the version is a stable version (not starting at 0 and not suffixed with a pre-release tag):
  • publish to hackage by prefixing the version number with 0.. Or maybe I will pick something different in order to remove the "unstable" feeling that we have when looking at version number starting with 0. Maybe I will prefix it either 1. or 42.

And finally, I simply don't publish non-final versions to hackage, forcing users to depend on the git repository directly.
For versions that are not published, I don't write any version number in the cabal/stack file.

Not being able to share work in progress is a shame, but I don't see what else I could do...

do you create tag after semver or PVP version? In other words, do your tags contain the leading 0. ?

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 my package.yaml. Intention or perspective doesn't matter once it's been set for the package.

Okay, I think I know what I will do.

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 pre0.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 push 0.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.

Regardless of how I'm bringing a SemVer perspective, or being PVP compliant, the version is the version: whatever string comes after version: in my package.yaml. Intention or perspective doesn't matter once it's been set for the package.

Well, we cannot write arbitrary version numbers after version: in package.yaml. Stack fails to build if I write 1.0.0-alpha.1 in my package.yaml.

That's why I have to include how to deal with this limitation in my process :-/