[RFC] Make PVP ecosystem/language agnostic

[hasufell]

Following discussion at https://github.com/haskell/pvp/pull/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.

[velveteer]

I'm inclined to agree with @phadej. In my experience, coming from maintaining other libraries with semver, PVP has been confusing and likely not what I would reach for in another language. Mainly due to that extra major version and not the API definitions (which I consider helpful, if somewhat outdated).

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

Is it feasible for Hackage to enforce this? You say PVP is a maintenance mess but then suggest its enforcement would be a better status quo? In the current state of PVP, I imagine this might start to look like Stackage.

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

Is tying API definitions to the version structure really hampering progress? I'm a bit new here so forgive me for being out of the loop, but if stagnation in PVP is the concern...why can't we freshen it up? Defining the public API for a GHC package appears to be a hard problem, and I don't think this proposal would make that any easier.

Soft no from me.

[parsonsmatt]

The PVP is barely followed in Haskell. I doubt that making it language agnostic would do anything for anyone but make it even more difficult to interpet how it applies to Haskell packages.

I think we'd probably be better off if we just deleted it entirely and said "We use SemVer but with two major versions For Fun"

[angerman]

I tend to agree with @parsonsmatt here. If we split this why retain PVP and not just drop it outright and say it's SemVer with double major versions? Does language agnostic part of PVP add enough value over semver to justify it?

We could also scrap the PVP discussions and have a hackage package policy, that contained the "suggested" (due to lack of enforcement) version considerations (what constitutes a breaking change; and why).

[hasufell]

Sorry, but semver is totally out of scope and not part of this discussion.

You'd break all Haskell tools in existence migrating to it. PVP and semver are not compatible.

E.g.

• valid PVP: 2.3.0.1
• valid semver: 1.0.0-alpha+001

You can't convert between those without defining some private encoding.

I'm baffled by these suggestions. And I am not interested in that discussion, honestly. Feel free to create an RFC for it.

[angerman]

To be clear here. I do think that separating concern is a good idea. I'm just not convinced that the language agnostic PVP will bring enough to the table that it stands on it's own.

I do believe guidance into what constitutes a breaking change is valuable. If it's not enforced in some way, probably less. Having this discussion written down somewhere explicitly certainly can help interested parties though.

If separation of concerns reduces tension by all means let's do it.

[gbaz]

This is a firm no from me. This doesn't just "separate concerns" but removes entirely all the most useful parts of the pvp (the meaning of a breaking change) and delegates them to an unclear other authority. If anyone doesn't want that authority delegated to them, they're welcome to step back from contributing to or discussing on this repo. And anyone who wants to play a role in discussions can hop into tickets on this repo. Moving the problem to an unspecified elsewhere makes sorting it out (and it does need to be sorted out) not one whit easier.

On a side note, we can't enforce pvp on hackage without a riot, but we can certainly have future work to encourage it more thoroughly, included through automated checks, badges and the like, and I'd like to see that in the future. (PRs welcome!)

Edit, btw: "It doesn't seem so, otherwise hackage would enforce it and we wouldn't have revisions." is a red herring. Even assuming a package repository with all packages pvp compliant, revisions would still be extremely useful, since it would allow authors to revise upper bounds upwards in the case of a major version bump on a dependency which did not cause breakage, without forcing upload of a new package. In fact, this is the ideal case for revisions, and one of the motivating factors in their design.

[hasufell]

If anyone doesn't want that authority delegated to them, they're welcome to step back from contributing to or discussing on this repo.

That's not a very welcoming statement for contributors, given that the actual meaning of API depends entirely on a non-CLC authority (GHC HQ and GHC SC).

I'm also not sure if this statement means you're inclined to step up and update PVP or whether you're just suggesting to let the spec rot for another 10 years.

[Bodigrim]

Folks, let's tread more carefully and clarify each other's intentions before jumping to conclusions.

FWIW I think that it would be nice to roll out PVP 1.1 soon (= within 6 months), but we need some concentrated effort to tie loose ends.

[hasufell]

I don't think I require further input. Thanks all.