Update PVP specification to mention non-leading zeros

[psilospore]

Wasn't sure where to put this. Feel free to suggest moving it elsewhere. It didn't seem like it fit in the bullet points. Based on a conversation in the Haskell Foundation slack: https://haskell-foundation.slack.com/archives/C01PKJ9QKJ8/p1640106505142800

[cartazio]

Sounds good to me. Who has perms ?

[Kleidukos]

@gbaz ?

[Bodigrim]

There are two general issues with PVP changes.

1. Which versioning schema should be used for PVP itself? So far PVP used to be immutable and does not have a version at all.

2. Who is responsible to maintain and evolve PVP? Is it CLC, Hackage admins/trustees, Hackage.org committee, or someone else?

[Kleidukos]

@Bodigrim Since this PR involves a clarification of a behaviour that was already enacted by tooling like Cabal, I don't think we should concern ourselves with version changes.

Regarding 2), it feels very muddied, but from what I can see nobody is in charge, but the website falls under haskell.org

[Bodigrim]

@Kleidukos nevertheless this is still a (breaking) change (which I’m fully in favor of).

[gbaz]

Its not a breaking change in the sense that it documents what the cabal library is capable of parsing more accurately. Versioning that did not follow this rule would simply have not worked, regardless. I think historically the hackage trustees managed this repo.

[hasufell]

Its not a breaking change in the sense that it documents what the cabal library is capable of parsing more accurately. Versioning that did not follow this rule would simply have not worked, regardless. I think historically the hackage trustees managed this repo.

Assuming Cabal is the only user of PVP.

[Bodigrim]

For the purpose of (1) it is not really important whether this change is breaking or not. It is a change, it should be reflected in a version/revision number of the specification.

[gbaz]

Well there is no version number of the specification, because it is not a specification of a grammar, it is a version policy. It sort of incidentally discusses the grammar along the way. This document has not evolved as a spec, has not had an approvals process as a spec, and has not had versioning numbers. shrug

[phadej]

Which versioning schema should be used for PVP itself? So far PVP used to be immutable and does not have a version at all.

This repository has v1.0 and v1.1 folders. With v1.1 being still draft, IIRC.

https://groups.google.com/g/haskell-core-libraries/c/BKu8iSKnIyo/m/fQ74w736AgAJ

---

2. Who is responsible to maintain and evolve PVP? Is it CLC, Hackage admins/trustees, Hackage.org committee, or someone else?

https://github.com/haskell/pvp#proposing-changes says

Formally, the PVP is maintained by the Core Libraries Committee together with the Hackage Trustees.

https://groups.google.com/g/haskell-core-libraries/c/xkJT8HEh7tM

[gbaz]

Thanks for the clarifying links Oleg! I guess the CLC can take this up at their next meeting.

[Bodigrim]

@gbaz would you be happy for CLC to claim PVP maintainership alone? Or would you like to setup a decision-making process, involving Hackage Trustees in a formal way? Given that Trustees are unelected and somewhat amorphous body, I'm hesitant to make them in full an integral part of decision making. Maybe we can have a joint committee of CLC and Hackage Admins (essentially embodied in @gbaz)?

[gbaz]

I think that the CLC could take responsibility on its own, with the caveat that no significant (non-bug) changes should be made without consultation with and approval of the hackage admins.

[Bodigrim]

Sounds good. Is it possible to clarify who are current hackage admins? https://hackage.haskell.org/users/admins/ does not look fully up to date. (Not that I have any appetite for significant changes, just to future-proof the decision-making structure)

[gbaz]

Afaik everyone except Ben is considered an admin, though only Erik and myself are at all active.

[Bodigrim]

@psilospore could you please retarget this to v1.1 folder? Once done, CLC will be able to hold a vote.

[bergmark]

Side-track, but thanks for letting me know about v1.1.

Deprecation (§7) is not considered a breaking change anymore and merely requires a minor version increment with PVP-1.1 (https://github.com/haskell/pvp/issues/12[](https://github.com/haskell/pvp/blob/master/v1.1/pvp-specification.md#appendix))

Great change!

[psilospore]

Updated sorry about the delay!

[Bodigrim]

Dear CLC members, let's vote on this change to (yet unreleased) PVP 1.1 specification. It codifies a long-standing practice of Cabal, see https://hackage.haskell.org/package/Cabal-3.6.2.0/docs/Distribution-Types-Version.html#v:validVersion, and as such is a minor change. @tomjaguarpaw @chessai @emilypi @cigsender @cgibbard

---

+1 from me.

[mixphix]

Can't see why a sane implementation of version parsing would allow negative numbers. +1 from me.

[tomjaguarpaw]

+1

[Bodigrim]

@chessai @emilypi @cigsender @cgibbard just a gentle reminder to vote.

[Bodigrim]

@chessai @emilypi @cgibbard this is the 3rd reminder to vote.

[hasufell]

Now that we defined a minBound... how about defining a maxBound?

[Bodigrim]

Let's leave this for a separate discussion please.

[chessai]

+1

[emilypi]

+1

[Bodigrim]

5 votes in favor are enough for CLC approval, but apparently I do not have rights to merge. @gbaz @chessai @emilypi could someone of you grant me necessary powers?

[chessai]

5 votes in favor are enough for CLC approval, but apparently I do not have rights to merge. @gbaz @chessai @emilypi could someone of you grant me necessary powers?

You have been granted access. In the meantime, I have merged