[PVP] PVP-1.0, PVP-1.1 & Deprecation clause

[Herbert Valerio Riedel]

Hello CLC & Trustees,

This is both an overdue follow-up to

https://groups.google.com/forum/#!topic/haskell-core-libraries/xkJT8HEh7tM

as well as a heads-up about some work in progress:

----

Prompted by today's *major* `network-3.1.0.0` release (see
https://github.com/haskell/network/issues/401) which adhered to the
currently published PVP specification (hereinafter denoted as "PVP-1.0")
whose primary justification for the major version bump turned out to be
the mere addition of a DEPRECATION annotation I invested a bit of time
to start on a PVP-1.1 draft.

So this is basically about two significant changes I made so far in the
Git source:


I.) Implement/introduce the concept of versioning of the PVP spec itself

https://github.com/haskell/pvp/commit/b69f18c51f1c84a131fe184faf474b7354ab85ae

TLDR, it's a relatively informal 2-part version x.y and there is no
formal meta-versioning specification in place yet that informs the meaning
of the version-deltas x.(y+1) vs. (x+1).0; and it's supposed to only
track actual semantic changes of the spec (and i.e. not merely
typofixes, rewordings or minor clarifications)

If it turns out we need this, this can of course be formalised more; but
for now I consider the introduction of versioning a means to an end for
enabling b)



II.) Weaken the Deprecation-clause to only require a minor instead of a
major version signal.

The rationale was outlined already in

https://github.com/haskell/pvp/issues/12

and which appeared to have clear approval from those who commented
(including from a couple CLC members)

I brought this also up on the CLC list in 2016, see

https://groups.google.com/forum/#!topic/haskell-core-libraries/HCAepXp0NKg

while I have already included this change in the PVP-1.1 draft (partly
also as a proof of concept to see how the versioned PVP Hakyll-site
"feels")...

https://github.com/haskell/pvp/blob/master/v1.1/pvp-specification.md

...this by no means is supposed to be a fait accompli.


Long story short, I'd like to ask you, the current CLC members and
Trustees, whether there's any opposition against I) and more
importantly against II) described above.

----

As this email is already long enough and I'd prefer to have focused
discussion threads, I'll write a separate email at a later time to
suggest/discuss the further process/roadmap for the minor PVP 1.1 spec
update.


Best,
Herbert

[George Wilson]

Hi Herbert,

Thanks for the detailed summary with links. It has helped me come up
to speed on this situation and no doubt other new members too.

I don't oppose I or II. Something simple like the meta-versioning
scheme you've proposed seems like a good fit. It could be fleshed out
later as needed.

Cheers,
George

[Edward Kmett]

Am I the only one amused the versioning of the PVP follows semver rather than the PVP?

-Edward

> --
> You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Carter Schonwald]

Hrmmm. That does seem to a weakness of the proposal.

By semver you mean major.minor syntax ?

-Carter

[Herbert Valerio Riedel]

On Thu, May 2, 2019 at 4:07 PM Edward Kmett <ekm...@gmail.com> wrote:

Am I the only one amused the versioning of the PVP follows semver rather than the PVP?

Well, I picked intentionally a 2-part versioning number, to avoid any resemblence to either SemVer or PVP ;-)

I'm totally happy to go with

- PVP-1.0.0

- PVP-1.0.1

if there's no risk to be misinterpreted as a 3-part  SemVer-style versioning :-)

but still, we don't yet have defined any formal meta-versioning scheme for the versioning policy... so calling this either SemVer or PVP isn't applicable at this time yet, IMO.

There's definitely some intuition for whether there's compatibility or not (and thus define the increment-size) in terms of e.g. whether a package providing an API is adhering to version X of the PVP is still sound when interpreted by a consuming package in terms of a version Y of the PVP. And maybe we should just use this as the definition.

[Oleg Grenrus]

Is there any progress on this process. It has been almost two months
without any visible activity?

- Oleg