[RFC] Make PVP ecosystem/language agnostic

[hasufell]

Following discussion at #51 and https://discourse.haskell.org/t/the-operator-in-cabal-files/6938/59?u=hasufell I'm starting to question why the specification mentions:

1. Haskell (language)
2. Cabal and hackage (ecosystem)

I feel it's odd that a pacakge version policy talks about ecosystem effects, build tools and package serving backends.

That makes it a poor spec, in my opinion. The core of it should deal only with versioning and be very abstract about what constitutes public/visible API.

There have been multiple discussions that have constantly creeped into PVP:

1. how to deal with upper bounds
2. what exactly is API (this line gets blurry with some advanced GHC extensions etc)

I think part 1 is up to hackage and the ecosystem to decide. They can use whatever superset of the spec they want, describe upper bound policies, tooling and so on.

Part 2 is up to GHC HQ/SC to decide. The PVP maintainers shouldn't make those decisions.

---

As such, I propose to make PVP fully language and ecosystem agnostic.

[hasufell]

As a comparison, semver speaks nothing of dependencies or how to specify lower/upper bounds: https://semver.org/

There's an implicit mention of this in the motivation, but it refrains from specifying any of that. For good reasons.

[phadej]

Please don't.

PVP "works" because it is specific. It clearly defines what is breaking change and what isn't. People argue what is breaking change in say JavaScript + semver setup. And disagree. That is bad. EDIT: In particular semver is bad because it is vague. (Semver was designed with dynamically typed languages in mind, there are no "compiler" to definitely tell that stuff breaks, so it has to be vague, PVP doesn't need to).

what exactly is API (this line gets blurry with some advanced GHC extensions etc)

Then PVP has to be kept up to date with a language.

Part 2 is up to GHC HQ/SC to decide. The PVP maintainers shouldn't make those decisions.

It's not. Breaking changes as specified in PVP today cause compilation errors. (Semantic changes are a big vague). GHC HQ/SC should design the features so it's easy to decide if feature's particular usage will cause breakage downstream. And mostly it is easy to work out what are the breaking changes.

For example: reordering variables in forall is technically a breaking change as downstream TypeApplications users may break. Does this make TypeApplications badly designed? I wouldn't say so.

What if we get NamedTypeApplications, like foo @{m = Identity}? Then renaming variables could break downstream. Does this make that feature not welcome? It's for GHC SC to decide.

[hasufell]

PVP "works" because it is specific.

It doesn't seem so, otherwise hackage would enforce it and we wouldn't have revisions.

Enabling a proper ecosystem is about much more than just a version policy. I think most of the text in PVP is misplaced. We're free to develop a "Hackage version policy" on top of PVP, which can more easily reflect the state of tooling etc.

A version spec that depends on tooling is not a good spec.

[phadej]

PVP is the Hackage versioning policy. You don't need to use PVP if you are not uploading packages to Hackage.

If you need different policy for different needs, make one, don't repurpose PVP.

[hasufell]

PVP is the Hackage versioning policy.

Yes and this RFC seeks to change that.

You don't need to use PVP if you are not uploading packages to Hackage.

You don't need to use semver if you're not uploading to crates.io?

Sorry, that makes no sense to me.

If you need different policy for different needs, make one, don't repurpose PVP.

Yes, it's very bad form if someone wants to depend on the reasonable core parts of PVP and apply it to a different language or ecosystem, because it's intertwined with Haskell, hackage, Cabal and whatnot.

From the hackage point of view, nothing might really change: the non-core parts can just be moved out and be governed by hackage trustees or someone else.

[phadej]

What are "the reasonable core parts of PVP"? "Make major version bump when you make a breaking change?" That's probably in all semantic versioning policies.

I repeat myself: the power of PVP is because it gives concrete lists what are considered breaking changes etc (e.g. adding an orphan instance - something which is not obvious at first). That's very Haskell specific, and that is a good thing.

[hasufell]

What are "the reasonable core parts of PVP"? "Make major version bump when you make a breaking change?" That's probably in all semantic versioning policies.

Look at semver: https://semver.org/

It is much shorter and much more popular than PVP.

I repeat myself: the power of PVP is because it gives concrete lists what are considered breaking changes etc (e.g. adding an orphan instance - something which is not obvious at first). That's very Haskell specific, and that is a good thing

And I repeat myself: hackage can have a separate spec/policy based on PVP that says all those same things. Right now, it doesn't even enforce PVP and the document is outdated and doesn't reflect the current state. What's the point?

[phadej]

It is much shorter and much more popular than PVP.

JavaScript (and Ruby IIRC) are more popular than Haskell.

And I repeat myself: hackage can have a separate spec/policy based on PVP that says all those same things.

And what is gained by that? I don't understand.

if someone wants to depend on the reasonable core parts of PVP and apply it to a different language or ecosystem

Does any, have you something in mind?

doesn't reflect the current state.

The current state is in balance. Many enough maintainers follow PVP so the the whole is robust.

[hasufell]

And what is gained by that? I don't understand.

Motivation is manyfold:

• other languages and ecosystem can more easily adopt PVP: it becomes a better spec
• PVP maintainers don't have to be bothered with constant bikeshedding about hackage issues, upper bounds, "what does API mean in Haskell" etc.
• hackage can be more aggressive and innovative with their policies and can develop them independently/on top of PVP and consider and develop tooling

[phadej]

PVP maintainers don't have to be bothered with constant bikeshedding about hackage issues, upper bounds, "what does API mean in Haskell" etc.

These are partially the same people as would do

hackage can be more aggressive and innovative with their policies and can develop them independently/on top of PVP and consider and develop tooling

Also "what does API mean in Haskell" is exactly one of the difficult parts which PVP tries to address.

PVP without Haskell specifities is "just" as semver with double major versions (and without everything can happen 0.x.y series of PVP), as the PVP vs SemVer faq entry describes.

I disagree that PVP without Haskell specifics would become a better spec. It would become a vague policy which would require an additional documents to pinpoint vague terms like "breaking change", e.g. something like https://doc.rust-lang.org/cargo/reference/semver.html#api-compatibility. I don't see how anything is gained in that setup.

[hasufell]

Also "what does API mean in Haskell" is exactly one of the difficult parts which PVP tries to address.

Yes and to repeat myself: it has no proper answer and has nothing to do with a version spec.

PVP without Haskell specifities is "just" as semver with double major versions (and without everything can happen 0.x.y series of PVP), as the PVP vs SemVer faq entry describes.

Correct.

I disagree that PVP without Haskell specifics would become a better spec

Yes, I think you made your opinion sufficiently clear.

[tomjaguarpaw]

@hasufell, is another way of stating your point that the PVP has two components which could be separated:

1. a version numbering scheme for indicating different types of breakage (not Haskell specific)
2. a determination of which API changes should be classified as which sorts of breakage (Haskell specific)

[hasufell]

@tomjaguarpaw yes, but there's also

3. how to specify version ranges for your dependencies

All those are very different concerns. Good specs, like semver, only cover 1.

Point 2 and 3 have stagnated terribly, as can be seen by the lack of inclusion of the caret operator, the lack of explaining what API means in light of newer GHC extensions and the lack of any progress on the cabal tooling that's promised in the faq.

This makes PVP a maintenance mess.

Hackage doesn't even enforce PVP, which is even more confusing. Status quo is unsatisfactory.

By splitting out the core of PVP, this will allow anyone to:

1. easily and strictly adhere to PVP
2. define what API means for a given language (Haskell2010 or GHC2021 or an entirely different language)... it is very odd that PVP is an authoritative source on that and it's a lot of work
3. set their own rules and policies for what packages will be accepted into an ecosystem and how dependency bounds have to be specified (e.g. it could reject packages without lower bounds and treat >= 2.0.0 as syntax sugar for >= 2.0.0 && < 2.1.0... or whatever else)

Once these concerns are segregated, we may be able to make better progress.

[hasufell]

@Bodigrim I'd like to trigger an informal vote about whether we want to work towards removing API definition concerns from the spec and make PVP language agnostic.

It is likely much more work to hash out exact wording etc. and I won't invest time in it, unless there's some consensus amongst PVP maintainers that it's a desirable outcome.

[Bodigrim]

Dear CLC members, could you please opine on the intention to split PVP into language-agnostic and Haskell-specific parts as explained above.

CC @tomjaguarpaw @mixphix @angerman @parsonsmatt @velveteer

Also CC @gbaz on behalf of Hackage Admins.

---

I'm leaning against this idea. It sounds reasonable to separate concerns, but IMO practically it's a lot of work for little benefit, and a risk to cause confusion. It seems unlikely that we gain adoption of Haskell-agnostic PVP by other ecosystems.