Re: Versioning of libraries bundled with GHC pre-releases

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Versioning of libraries bundled with GHC pre-releases

Dan Burton
+1 I would appreciate this.

-- Dan Burton

On Tue, Jan 16, 2018 at 10:35 AM, Ben Gamari <[hidden email]> wrote:

TL;DR. We propose to start following the PVP for core libraries shipped
       with GHC alpha release. Let us know what you think.


Hello everyone,

GHC has recently been reworking its release policy, increasing the
release cadence to two releases per year. We hope that this change
facilitates earlier and more thorough testing of GHC. Of course,
a compiler is worth little if no real-world packages can be built with
it.

Historically library maintainers have been reluctant to offer releases
claiming compatibility with pre-release GHCs due to the lax versioning
guarantees offered by such pre-releases. Specifically, changes to
libraries shipped with GHC pre-releases have historically not had
proper distinct version numbers, causing unnecessary breakage for
released code (e.g. [1]).

To make maintainers feel more at ease with releasing libraries
compatible with GHC alpha releases, we propose to start using the
Package Versioning Policy (PVP) [2] to version GHC's core libraries with
each alpha release. That is, libraries which are not source-identical
will get at very least a minor bump with each alpha release.

By "core libraries" we mean the set of:

 * base
 * template-haskell
 * integer-gmp
 * integer-simple
 * hpc
 * ghci
 * ghc-compact
 * all GHC dependencies not maintained by GHC HQ
 * ghc-prim
 * ghc-boot
 * ghc-boot-th

Following the PVP will allow maintainers to safely release libraries to
Hackage without fear that they will break when the final GHC 8.4.1
release is made, easing the testing process for everyone.

If you have an opinion one way or another on this matter please do share
it on this list.

Cheers,

- Ben


[1] https://github.com/tibbe/hashable/issues/143
[2] https://pvp.haskell.org/

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Versioning of libraries bundled with GHC pre-releases

Oleg Grenrus
Hi Ben,

Note that PVP dictates to do _major_ bump every time a breaking changes
is introduced:

1. Breaking change. If any entity was removed, or the types of any
entities or the definitions of datatypes or classes were changed, or
orphan instances were added or any instances were removed, then the
new A.B MUST be greater than the previous A.B.

This means that first alpha-release for e.g. GHC-8.4.1/base-4.11.0.0 or
GHC-8.6.1/base-4.12.0.0 will force to freeze both GHC and base.

For example "Make the Div and Mod type families `infixl 7`" commit
https://github.com/ghc/ghc/commit/fdfaa56b04b2cefb86e4dc557b1d163fd2e062dc
is a breaking change. OTOH it's pity not to fix new feature before it's
officially released.

I cannot judge how much ghc-the-lib public API changes.

TL;DR first alpha release is too early to do "PVP dictated freeze".

I think that we need *staging* (mutable) package repository, where
package authors can upload packages using lighter release procedure.
Let's keep Hackage to high standards, and test in a staging environment,
not the production one.

- Oleg

On 16.01.2018 20:35, Ben Gamari wrote:

> TL;DR. We propose to start following the PVP for core libraries shipped
>        with GHC alpha release. Let us know what you think.
>
>
> Hello everyone,
>
> GHC has recently been reworking its release policy, increasing the
> release cadence to two releases per year. We hope that this change
> facilitates earlier and more thorough testing of GHC. Of course,
> a compiler is worth little if no real-world packages can be built with
> it.
>
> Historically library maintainers have been reluctant to offer releases
> claiming compatibility with pre-release GHCs due to the lax versioning
> guarantees offered by such pre-releases. Specifically, changes to
> libraries shipped with GHC pre-releases have historically not had
> proper distinct version numbers, causing unnecessary breakage for
> released code (e.g. [1]).
>
> To make maintainers feel more at ease with releasing libraries
> compatible with GHC alpha releases, we propose to start using the
> Package Versioning Policy (PVP) [2] to version GHC's core libraries with
> each alpha release. That is, libraries which are not source-identical
> will get at very least a minor bump with each alpha release.
>
> By "core libraries" we mean the set of:
>
>  * base
>  * template-haskell
>  * integer-gmp
>  * integer-simple
>  * hpc
>  * ghci
>  * ghc-compact
>  * all GHC dependencies not maintained by GHC HQ
>  * ghc-prim
>  * ghc-boot
>  * ghc-boot-th
>
> Following the PVP will allow maintainers to safely release libraries to
> Hackage without fear that they will break when the final GHC 8.4.1
> release is made, easing the testing process for everyone.
>
> If you have an opinion one way or another on this matter please do share
> it on this list.
>
> Cheers,
>
> - Ben
>
>
> [1] https://github.com/tibbe/hashable/issues/143
> [2] https://pvp.haskell.org/
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Versioning of libraries bundled with GHC pre-releases

Ben Gamari-3
Oleg Grenrus <[hidden email]> writes:

> Hi Ben,
>
> Note that PVP dictates to do _major_ bump every time a breaking changes
> is introduced:
>
Right; this is what I was trying to imply when I said "at least a minor
bump" in the initial email.

> 1. Breaking change. If any entity was removed, or the types of any
> entities or the definitions of datatypes or classes were changed, or
> orphan instances were added or any instances were removed, then the
> new A.B MUST be greater than the previous A.B.
>
> This means that first alpha-release for e.g. GHC-8.4.1/base-4.11.0.0 or
> GHC-8.6.1/base-4.12.0.0 will force to freeze both GHC and base.
>
> For example "Make the Div and Mod type families `infixl 7`" commit
> https://github.com/ghc/ghc/commit/fdfaa56b04b2cefb86e4dc557b1d163fd2e062dc
> is a breaking change. OTOH it's pity not to fix new feature before it's
> officially released.
>
Yes, the fact that this sort of thing would require a decision between a
major bump or punting until the next release is terribly unfortunate.
In an idea world we would simply "be careful" and make sure tha major
interface decisions are made by the time of the first alpha but
unfortunately, as the above commit illustrates, mistakes are bound to
happen. I don't know the right compromise here.

> I cannot judge how much ghc-the-lib public API changes.
>
> TL;DR first alpha release is too early to do "PVP dictated freeze".
>
This may well be so. Hopefully this thread will help us determine the
costs and benefits of freezing during the alpha phase.

> I think that we need *staging* (mutable) package repository, where
> package authors can upload packages using lighter release procedure.
> Let's keep Hackage to high standards, and test in a staging environment,
> not the production one.
>
That is reasonable; however, I am a bit worried that our current tooling
isn't quite up to the task. Herbert's head.hackage effort is a great
start, but I fear that the friction of maintaining and using the
patchset may hamper adoption.

Cheers,

 - Ben

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (497 bytes) Download Attachment