Release policies

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

Release policies

GHC - devs mailing list

Dear GHC devops group

The conversation on Trac #14558 suggests that we might want to consider reviewing GHC’s release policies.  This email is to invite your input.

The broad questions is this. We want GHC to serve the needs of all its users, including downstream tooling that uses GHC.  What release policies will best support that goal?  For example,  we already ensure that GHC 8.4 can be compiled with 8.2 and 8.0.  This imposes a slight tax on GHC development, but it means that users don't need to upgrade quite as often.   (If the tempo of releases increases, we might want to increase the window.)

Trac #14558 suggests that we might want to ensure the metadata on GHC’s built-in libraries is parsable with older Cabals.  One possibility would be this:

  • Ensure that the Cabal metadata of non-reinstallable packages (e.g. integer-gmp) shipped with GHC be parsable by the Cabal versions shipped with the last two major GHC releases [i.e. have a sufficiently old cabal-version field].  That is, in general a new Cabal specification will need to be shipped with two GHC releases before GHC will use start using its features in non-reinstallable packages.
  • Upholding this policy won't always be possible. There may be cases (as is the case Hadrian for GHC 8.4) where the benefit of quickly introducing incompatible syntax outweighs the need for compatibility. In this (hopefully rare) case we would explicitly advertise the incompatibility in the release documentation, and give as much notice as possible to users to allow downstream tools to adapt.
  • For reinstallable packages, of which GHC is simply a client (like text or bytestring), we can’t reasonably enforce such a policy, because GHC devs have no control over what the maintainers of external core libraries put in their Cabal files.

This is just a proposal.  The narrow questions are these:

  • Would this be sufficient to deal with the concerns raised in #14558?
  • Is it necessary, ow would anything simpler be sufficient?
  • What costs would the policy impose on GHC development?
  • There may be matters of detail: e.g. is two releases the right grace period. Would one do?

Both the broad question and the narrow ones are appropriate for the Devops group.

Thanks!

Simon


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Release policies

Boespflug, Mathieu
[replying to ghc-devops-group@, which I assume based on your email's content is the mailing list you intended.]

Hi Simon,

feedback from downstream consumers of Cabal metadata (e.g. build tool authors) will be particularly useful for the discussion here. Here are my thoughts as a bystander.

It's worth trying to identify what problems came up during the integer-gmp incident in Trac #14558:

* GHC 8.2.1 shipped with integer-gmp-1.0.1.0 but the release notes said otherwise.
* GHC 8.2.1 shipped with Cabal-2.0.0.2, but specifically claimed in the release notes that cabal-install-1.24 (and by implication any other build tool based on Cabal-the-library version 1.24) was supported: "GHC 8.2 only works with cabal-install version 1.24 or later. Please upgrade if you have an older version of cabal-install."
* GHC 8.2.2 also claimed Cabal-1.24 support.
* GHC 8.2.1 was released in July 2017 with Cabal-2.0.0.2, a brand new major release with breaking changes to the metadata format, without much lead time for downstream tooling authors (like Stack) to adapt.
* But actually if we look at their respective release notes, GHC 8.2.1 was relased in July 2017, even though the Cabal website claims that Cabal-2.0.0.2 was released in August 2017 (see https://www.haskell.org/cabal/download.html). So it looks like GHC didn't just not give enough lead time about an upstream dependency it shipped with, it shipped with an unreleased version of Cabal!
* Libraries that ship with GHC are usually also uploaded to Hackage, to make the documentation easily accessible, but integer-gmp-1.0.1.0 was not uploaded to Hackage until 4 months after the release.
* The metadata for integer-gmp-1.0.1.0 as uploaded to Hackage differed from the metadata that was actually in the source tarball of GHC-8.2.1 and GHC-8.2.2.
* The metadata for integer-gmp-1.0.1.0 as uploaded to Hackage included Cabal-2.0 specific syntactic sugar, making the metadata unreadable using any tooling that did not link against the Cabal-2.0.0.2 library (or any later version).
* It so happened that one particular version of one particular downstream build tool, Stack, had a bug, compounding the bad effects of the previous point. But a new release has now been made, and in any case that's not a problem for GHC to solve. So let's keep that out of the discussion here.

So I suggest we discuss ways to eliminate or reduce the likelihood of any of the above problems from occurring again. Here are some ideas:

* GHC should never under any circumstance ship with an unreleased version of any independently maintained dependency. Cabal is one such dependency. This should hold true for anything else. We could just add that policy to the Release Policy.
* Stronger still, GHC should not switch to a new major release of a dependency at any time during feature freeze ahead of a release. E.g. if Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe it's fair game to include in GHC. But not if Cabal-3.0.0 hasn't shipped yet.
* The 3-release backwards compat rule should apply in all circumstances. That means major version bumps of any library GHC ships with, including base, should not imply any breaking change in the API's of any such library.
* GHC does have control over reinstallable packages (like text and bytestring): GHC need not ship with the latest versions of these, if indeed they introduce breaking changes that would contravene the 3-release policy.
* Note: today, users are effectively tied to whatever version of the packages ships with GHC (i.e. the "reinstallable" bit is problematic today for various technical reasons). That's why a breaking change in bytestring is technically a breaking change in GHC.
* The current release policy covers API stability, but what about metadata? In the extreme, we could say a 3-release policy applies to metadata too. Meaning, all metadata shipping with GHC now and in the next 2 releases should be parseable by today's version of Cabal and downstream tooling. Is such a long lead time necessary? That's for build tool authors to say, and a point to negotiate with GHC devs.
* Because there are far fewer consumers of metadata than consumers of say base, I think shorter lead time is reasonable. At the other extreme, it could even be just the few months during feature freeze.
* The release notes bugs mentioned above and the lack of consistent upload to Hackage are a symptom of lack of release automation, I suspect. That's how to fix it, but we could also spell out in the Release Policy that GHC libraries should all be on Hackage from the day of release.

Finally, a question for discussion:

* Hackage allows revising the metadata of an uploaded package even without changing the version number. This happens routinely on Hackage today by the Hackage trustees. Should this be permitted for packages whose release is completely tied to that of GHC itself (like integer-gmp)?

Best,

Mathieu


On 13 December 2017 at 17:43, Simon Peyton Jones via ghc-devs <[hidden email]> wrote:

Dear GHC devops group

The conversation on Trac #14558 suggests that we might want to consider reviewing GHC’s release policies.  This email is to invite your input.

The broad questions is this. We want GHC to serve the needs of all its users, including downstream tooling that uses GHC.  What release policies will best support that goal?  For example,  we already ensure that GHC 8.4 can be compiled with 8.2 and 8.0.  This imposes a slight tax on GHC development, but it means that users don't need to upgrade quite as often.   (If the tempo of releases increases, we might want to increase the window.)

Trac #14558 suggests that we might want to ensure the metadata on GHC’s built-in libraries is parsable with older Cabals.  One possibility would be this:

  • Ensure that the Cabal metadata of non-reinstallable packages (e.g. integer-gmp) shipped with GHC be parsable by the Cabal versions shipped with the last two major GHC releases [i.e. have a sufficiently old cabal-version field].  That is, in general a new Cabal specification will need to be shipped with two GHC releases before GHC will use start using its features in non-reinstallable packages.
  • Upholding this policy won't always be possible. There may be cases (as is the case Hadrian for GHC 8.4) where the benefit of quickly introducing incompatible syntax outweighs the need for compatibility. In this (hopefully rare) case we would explicitly advertise the incompatibility in the release documentation, and give as much notice as possible to users to allow downstream tools to adapt.
  • For reinstallable packages, of which GHC is simply a client (like text or bytestring), we can’t reasonably enforce such a policy, because GHC devs have no control over what the maintainers of external core libraries put in their Cabal files.

This is just a proposal.  The narrow questions are these:

  • Would this be sufficient to deal with the concerns raised in #14558?
  • Is it necessary, ow would anything simpler be sufficient?
  • What costs would the policy impose on GHC development?
  • There may be matters of detail: e.g. is two releases the right grace period. Would one do?

Both the broad question and the narrow ones are appropriate for the Devops group.

Thanks!

Simon


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Fwd: Release policies

Boespflug, Mathieu
---------- Forwarded message ----------
From: Boespflug, Mathieu <[hidden email]>
Date: 13 December 2017 at 23:03
Subject: Re: Release policies
To: Simon Peyton Jones <[hidden email]>
Cc: [hidden email]


[replying to ghc-devops-group@, which I assume based on your email's content is the mailing list you intended.]

Hi Simon,

feedback from downstream consumers of Cabal metadata (e.g. build tool authors) will be particularly useful for the discussion here. Here are my thoughts as a bystander.

It's worth trying to identify what problems came up during the integer-gmp incident in Trac #14558:

* GHC 8.2.1 shipped with integer-gmp-1.0.1.0 but the release notes said otherwise.
* GHC 8.2.1 shipped with Cabal-2.0.0.2, but specifically claimed in the release notes that cabal-install-1.24 (and by implication any other build tool based on Cabal-the-library version 1.24) was supported: "GHC 8.2 only works with cabal-install version 1.24 or later. Please upgrade if you have an older version of cabal-install."
* GHC 8.2.2 also claimed Cabal-1.24 support.
* GHC 8.2.1 was released in July 2017 with Cabal-2.0.0.2, a brand new major release with breaking changes to the metadata format, without much lead time for downstream tooling authors (like Stack) to adapt.
* But actually if we look at their respective release notes, GHC 8.2.1 was relased in July 2017, even though the Cabal website claims that Cabal-2.0.0.2 was released in August 2017 (see https://www.haskell.org/cabal/download.html). So it looks like GHC didn't just not give enough lead time about an upstream dependency it shipped with, it shipped with an unreleased version of Cabal!
* Libraries that ship with GHC are usually also uploaded to Hackage, to make the documentation easily accessible, but integer-gmp-1.0.1.0 was not uploaded to Hackage until 4 months after the release.
* The metadata for integer-gmp-1.0.1.0 as uploaded to Hackage differed from the metadata that was actually in the source tarball of GHC-8.2.1 and GHC-8.2.2.
* The metadata for integer-gmp-1.0.1.0 as uploaded to Hackage included Cabal-2.0 specific syntactic sugar, making the metadata unreadable using any tooling that did not link against the Cabal-2.0.0.2 library (or any later version).
* It so happened that one particular version of one particular downstream build tool, Stack, had a bug, compounding the bad effects of the previous point. But a new release has now been made, and in any case that's not a problem for GHC to solve. So let's keep that out of the discussion here.

So I suggest we discuss ways to eliminate or reduce the likelihood of any of the above problems from occurring again. Here are some ideas:

* GHC should never under any circumstance ship with an unreleased version of any independently maintained dependency. Cabal is one such dependency. This should hold true for anything else. We could just add that policy to the Release Policy.
* Stronger still, GHC should not switch to a new major release of a dependency at any time during feature freeze ahead of a release. E.g. if Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe it's fair game to include in GHC. But not if Cabal-3.0.0 hasn't shipped yet.
* The 3-release backwards compat rule should apply in all circumstances. That means major version bumps of any library GHC ships with, including base, should not imply any breaking change in the API's of any such library.
* GHC does have control over reinstallable packages (like text and bytestring): GHC need not ship with the latest versions of these, if indeed they introduce breaking changes that would contravene the 3-release policy.
* Note: today, users are effectively tied to whatever version of the packages ships with GHC (i.e. the "reinstallable" bit is problematic today for various technical reasons). That's why a breaking change in bytestring is technically a breaking change in GHC.
* The current release policy covers API stability, but what about metadata? In the extreme, we could say a 3-release policy applies to metadata too. Meaning, all metadata shipping with GHC now and in the next 2 releases should be parseable by today's version of Cabal and downstream tooling. Is such a long lead time necessary? That's for build tool authors to say, and a point to negotiate with GHC devs.
* Because there are far fewer consumers of metadata than consumers of say base, I think shorter lead time is reasonable. At the other extreme, it could even be just the few months during feature freeze.
* The release notes bugs mentioned above and the lack of consistent upload to Hackage are a symptom of lack of release automation, I suspect. That's how to fix it, but we could also spell out in the Release Policy that GHC libraries should all be on Hackage from the day of release.

Finally, a question for discussion:

* Hackage allows revising the metadata of an uploaded package even without changing the version number. This happens routinely on Hackage today by the Hackage trustees. Should this be permitted for packages whose release is completely tied to that of GHC itself (like integer-gmp)?

Best,

Mathieu


On 13 December 2017 at 17:43, Simon Peyton Jones via ghc-devs <[hidden email]> wrote:

Dear GHC devops group

The conversation on Trac #14558 suggests that we might want to consider reviewing GHC’s release policies.  This email is to invite your input.

The broad questions is this. We want GHC to serve the needs of all its users, including downstream tooling that uses GHC.  What release policies will best support that goal?  For example,  we already ensure that GHC 8.4 can be compiled with 8.2 and 8.0.  This imposes a slight tax on GHC development, but it means that users don't need to upgrade quite as often.   (If the tempo of releases increases, we might want to increase the window.)

Trac #14558 suggests that we might want to ensure the metadata on GHC’s built-in libraries is parsable with older Cabals.  One possibility would be this:

  • Ensure that the Cabal metadata of non-reinstallable packages (e.g. integer-gmp) shipped with GHC be parsable by the Cabal versions shipped with the last two major GHC releases [i.e. have a sufficiently old cabal-version field].  That is, in general a new Cabal specification will need to be shipped with two GHC releases before GHC will use start using its features in non-reinstallable packages.
  • Upholding this policy won't always be possible. There may be cases (as is the case Hadrian for GHC 8.4) where the benefit of quickly introducing incompatible syntax outweighs the need for compatibility. In this (hopefully rare) case we would explicitly advertise the incompatibility in the release documentation, and give as much notice as possible to users to allow downstream tools to adapt.
  • For reinstallable packages, of which GHC is simply a client (like text or bytestring), we can’t reasonably enforce such a policy, because GHC devs have no control over what the maintainers of external core libraries put in their Cabal files.

This is just a proposal.  The narrow questions are these:

  • Would this be sufficient to deal with the concerns raised in #14558?
  • Is it necessary, ow would anything simpler be sufficient?
  • What costs would the policy impose on GHC development?
  • There may be matters of detail: e.g. is two releases the right grace period. Would one do?

Both the broad question and the narrow ones are appropriate for the Devops group.

Thanks!

Simon


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs




_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Release policies

Gershom Bazerman
In reply to this post by GHC - devs mailing list
Mathieu:

I think the points about better tooling for documenting the correct
claims in the release process are well taken. Updating the release
notes manually leaves way too much room for error.

However, I think you are incorrect that GHC 8.2.1 and 8.2.2 did not
have cabal-install 1.24 support. They did. it works with them. I used
it! The fact that the cabal files for builtin libraries use Cabal-2
syntax does not cause a problem.

I think elsewhere Mikhail has corrected your timeline a bit. The
general point is that Cabal-the-library and ghc releases do tend to be
in tandem. But it is also the case that this happens because they are
often developed in a coupled fashion. This in not really different
than other builtin libs to GHC. They are necessarily coupled to
changes in the compiler, and so end up being released together. Our
process for making sure they are actually uploaded is absolutely
error-prone as is the process for documenting what occurs in release
notes. But I don't think we can simply by fiat decouple this stuff --
rather, this needs to occur on a technical level first, before other
policies can really even be considered.

Onto the concrete ideas:

> * GHC should never under any circumstance ship with an unreleased version
> of any independently maintained dependency. Cabal is one such dependency.
> This should hold true for anything else. We could just add that policy to
> the Release Policy.

Yes, this is a good policy. Sometimes in the drive for a release, GHC
will run ahead of a dependencies' upload by a bit. (Iirc this happened
at one point in the past for bytestring, but this was some years ago).
It is always better to hold things by a few days to get the dependency
released first.

> * Stronger still, GHC should not switch to a new major release of a
> dependency at any time during feature freeze ahead of a release. E.g. if
> Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe it's fair
> game to include in GHC. But not if Cabal-3.0.0 hasn't shipped yet.

I don't think this works, in terms of coupled dependencies. If/when
Cabal-3 is developed it will almost certainly be in tandem with GHC
support.

> * GHC does have control over reinstallable packages (like text and
> bytestring): GHC need not ship with the latest versions of these, if indeed
> they introduce breaking changes that would contravene the 3-release policy.

Right, but this won't occur, because those libs are already under the
control of the libraries committee and abide by the policy.

> * Because there are far fewer consumers of metadata than consumers of say
> base, I think shorter lead time is reasonable. At the other extreme, it
> could even be just the few months during feature freeze.

Right. There's not a sufficient quantity of metadata-consuming
downstream tooling to motivate a long lead. And furthermore, the
examples I can think of -- tracking dependencies for notifications or
graphs -- have no need of pulling this data out of ghc-builtin
libraries anyway, as they're for exploring the _userland_ portion of
the package world regardless. (The other key example -- stack -- can
also choose to ignore the metadata of builtin libs without harm).

The general motivation of making a "feature freeze" more of a "freeze
all the moving parts, really" I do agree with. Having a real freeze is
part of a better release process, and it should allow all the
downstream consumers of everything more time to really catch up. This
is just one instance of that need.

> Finally, a question for discussion:
>
> * Hackage allows revising the metadata of an uploaded package even without
> changing the version number. This happens routinely on Hackage today by the
> Hackage trustees. Should this be permitted for packages whose release is
> completely tied to that of GHC itself (like integer-gmp)?

It is rare that this is needed, but the ability just served us well --
editing integer-gmp to remove the new syntax was very useful, as it
let us fix up old stack nightlies. Like all revisions, these should be
made with some care and thought, but since we've just seen why it was
helpful, I'd hate to now say we can't do it again if some other
unforseen circumstance crops up.

Regards,
Gershom

> Hi Simon,
>
> feedback from downstream consumers of Cabal metadata (e.g. build tool
> authors) will be particularly useful for the discussion here. Here are my
> thoughts as a bystander.
>
> It's worth trying to identify what problems came up during the integer-gmp
> incident in Trac #14558:
>
> * GHC 8.2.1 shipped with integer-gmp-1.0.1.0 but the release notes said
> otherwise.
> * GHC 8.2.1 shipped with Cabal-2.0.0.2, but specifically claimed in the
> release notes that cabal-install-1.24 (and by implication any other build
> tool based on Cabal-the-library version 1.24) was supported: "GHC 8.2 only
> works with cabal-install version 1.24 or later. Please upgrade if you have
> an older version of cabal-install."
> * GHC 8.2.2 also claimed Cabal-1.24 support.
> * GHC 8.2.1 was released in July 2017 with Cabal-2.0.0.2, a brand new major
> release with breaking changes to the metadata format, without much lead
> time for downstream tooling authors (like Stack) to adapt.
> * But actually if we look at their respective release notes, GHC 8.2.1 was
> relased in July 2017, even though the Cabal website claims that
> Cabal-2.0.0.2 was released in August 2017 (see
> https://www.haskell.org/cabal/download.html). So it looks like GHC didn't
> just not give enough lead time about an upstream dependency it shipped
> with, it shipped with an unreleased version of Cabal!
> * Libraries that ship with GHC are usually also uploaded to Hackage, to
> make the documentation easily accessible, but integer-gmp-1.0.1.0 was not
> uploaded to Hackage until 4 months after the release.
> * The metadata for integer-gmp-1.0.1.0 as uploaded to Hackage differed from
> the metadata that was actually in the source tarball of GHC-8.2.1 and
> GHC-8.2.2.
> * The metadata for integer-gmp-1.0.1.0 as uploaded to Hackage included
> Cabal-2.0 specific syntactic sugar, making the metadata unreadable using
> any tooling that did not link against the Cabal-2.0.0.2 library (or any
> later version).
> * It so happened that one particular version of one particular downstream
> build tool, Stack, had a bug, compounding the bad effects of the previous
> point. But a new release has now been made, and in any case that's not a
> problem for GHC to solve. So let's keep that out of the discussion here.
>
> So I suggest we discuss ways to eliminate or reduce the likelihood of any
> of the above problems from occurring again. Here are some ideas:
>
> * GHC should never under any circumstance ship with an unreleased version
> of any independently maintained dependency. Cabal is one such dependency.
> This should hold true for anything else. We could just add that policy to
> the Release Policy.
> * Stronger still, GHC should not switch to a new major release of a
> dependency at any time during feature freeze ahead of a release. E.g. if
> Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe it's fair
> game to include in GHC. But not if Cabal-3.0.0 hasn't shipped yet.
> * The 3-release backwards compat rule should apply in all circumstances.
> That means major version bumps of any library GHC ships with, including
> base, should not imply any breaking change in the API's of any such library.
> * GHC does have control over reinstallable packages (like text and
> bytestring): GHC need not ship with the latest versions of these, if indeed
> they introduce breaking changes that would contravene the 3-release policy.
> * Note: today, users are effectively tied to whatever version of the
> packages ships with GHC (i.e. the "reinstallable" bit is problematic today
> for various technical reasons). That's why a breaking change in bytestring
> is technically a breaking change in GHC.
> * The current release policy covers API stability, but what about metadata?
> In the extreme, we could say a 3-release policy applies to metadata too.
> Meaning, all metadata shipping with GHC now and in the next 2 releases
> should be parseable by today's version of Cabal and downstream tooling. Is
> such a long lead time necessary? That's for build tool authors to say, and
> a point to negotiate with GHC devs.
> * Because there are far fewer consumers of metadata than consumers of say
> base, I think shorter lead time is reasonable. At the other extreme, it
> could even be just the few months during feature freeze.
> * The release notes bugs mentioned above and the lack of consistent upload
> to Hackage are a symptom of lack of release automation, I suspect. That's
> how to fix it, but we could also spell out in the Release Policy that GHC
> libraries should all be on Hackage from the day of release.
>
> Finally, a question for discussion:
>
> * Hackage allows revising the metadata of an uploaded package even without
> changing the version number. This happens routinely on Hackage today by the
> Hackage trustees. Should this be permitted for packages whose release is
> completely tied to that of GHC itself (like integer-gmp)?
>
> Best,
>
> Mathieu
>
>
> On 13 December 2017 at 17:43, Simon Peyton Jones via ghc-devs <
> [hidden email]> wrote:
>
>> Dear GHC devops group
>>
>> The conversation on Trac #14558
>> <https://ghc.haskell.org/trac/ghc/ticket/14558> suggests that we might
>> want to consider reviewing GHC’s release policies
>> <https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases>.
>> This email is to invite your input.
>>
>> The broad questions is this. We want GHC to serve the needs of all its
>> users, including downstream tooling that uses GHC.  What release policies
>> will best support that goal?  For example,  we already ensure that GHC 8.4
>> can be compiled with 8.2 and 8.0.  This imposes a slight tax on GHC
>> development, but it means that users don't need to upgrade quite as often.
>>  (If the tempo of releases increases, we might want to increase the window.)
>>
>> Trac #14558 suggests that we might want to ensure the metadata on GHC’s
>> built-in libraries is parsable with older Cabals.  One possibility would be
>> this:
>>
>>    - Ensure that the Cabal metadata of non-reinstallable packages (e.g.
>>    integer-gmp) shipped with GHC be parsable by the Cabal versions shipped
>>    with the last two major GHC releases [i.e. have a sufficiently old
>>    cabal-version field].  That is, in general a new Cabal specification will
>>    need to be shipped with two GHC releases before GHC will use start using
>>    its features in non-reinstallable packages.
>>    - Upholding this policy won't always be possible. There may be cases
>>    (as is the case Hadrian for GHC 8.4) where the benefit of quickly
>>    introducing incompatible syntax outweighs the need for compatibility. In
>>    this (hopefully rare) case we would explicitly advertise the
>>    incompatibility in the release documentation, and give as much notice as
>>    possible to users to allow downstream tools to adapt.
>>    - For reinstallable packages, of which GHC is simply a client (like
>>    text or bytestring), we can’t reasonably enforce such a policy, because GHC
>>    devs have no control over what the maintainers of external core libraries
>>    put in their Cabal files.
>>
>> This is just a proposal.  The narrow questions are these:
>>
>>    - Would this be sufficient to deal with the concerns raised in #14558?
>>    - Is it necessary, ow would anything simpler be sufficient?
>>    - What costs would the policy impose on GHC development?
>>    - There may be matters of detail: e.g. is two releases the right grace
>>    period. Would one do?
>>
>> Both the broad question and the narrow ones are appropriate for the Devops
>> group.
>>
>> Thanks!
>>
>> Simon
>>
>> _______________________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171213/3c54ee2e/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ------------------------------
>
> End of ghc-devs Digest, Vol 172, Issue 15
> *****************************************
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Release policies

Boespflug, Mathieu
Hi Gerhom,

On 14 December 2017 at 00:19, Gershom B <[hidden email]> wrote:
>
> Mathieu:
>
> I think the points about better tooling for documenting the correct
> claims in the release process are well taken. Updating the release
> notes manually leaves way too much room for error.
>
> However, I think you are incorrect that GHC 8.2.1 and 8.2.2 did not
> have cabal-install 1.24 support. They did. it works with them.

They did, and indeed Stack too worked just fine with them, but that
was assuming that integer-gmp-1.0.1.0 really was what was shipped in
the tarballs, not what it was on Hackage (until it got recently
revised). I don't know which version of integer-gmp-1.0.1.0 was the
intended one. They both have the same version number and neither seems
more authoritative than the other to me. Had the Hackage one been the
one that shipped, then I'm not sure that cabal-install-1.24 would have
worked. Stack broke the moment what was on Hackage and what was in GHC
bindists did not line up anymore. And with release notes mentioning
incorrect version numbers, harder still to tell.

But crucially, what *is* the policy around Cabal versions? This
comment, https://ghc.haskell.org/trac/ghc/ticket/14558#comment:23
claims "if Stack doesn't support the version of Cabal that ships with
a certain version of GHC, it shouldn't claim that it supports that
version of GHC. The same applies to cabal-install". Is any build tool
linked against Cabal-X by definition "not a supported configuration"
by GHC-Z if it ships with Cabal-Y such that X < Y?

> > * Stronger still, GHC should not switch to a new major release of a
> > dependency at any time during feature freeze ahead of a release. E.g. if
> > Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe it's fair
> > game to include in GHC. But not if Cabal-3.0.0 hasn't shipped yet.
>
> I don't think this works, in terms of coupled dependencies. If/when
> Cabal-3 is developed it will almost certainly be in tandem with GHC
> support.

Right. But switching from Cabal-2 to Cabal-3 (a hypothetical at this
point) sounds like a whole new set of features transitively just made
it into the compiler. Is that something we're happy to happen during
feature freeze?

> The general motivation of making a "feature freeze" more of a "freeze
> all the moving parts, really" I do agree with. Having a real freeze is
> part of a better release process, and it should allow all the
> downstream consumers of everything more time to really catch up. This
> is just one instance of that need.

Agreed.

> > Finally, a question for discussion:
> >
> > * Hackage allows revising the metadata of an uploaded package even without
> > changing the version number. This happens routinely on Hackage today by the
> > Hackage trustees. Should this be permitted for packages whose release is
> > completely tied to that of GHC itself (like integer-gmp)?
>
> It is rare that this is needed, but the ability just served us well --
> editing integer-gmp to remove the new syntax was very useful, as it
> let us fix up old stack nightlies. Like all revisions, these should be
> made with some care and thought, but since we've just seen why it was
> helpful, I'd hate to now say we can't do it again if some other
> unforseen circumstance crops up.

I don't disagree. But then we'd need to abandon any notion that
versions of packages on Hackage and versions of packages in the GHC
release tarball always match up. Might even be worth calling that out
explicitly in the policy.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Release policies

Gershom Bazerman
On Wed, Dec 13, 2017 at 7:06 PM, Boespflug, Mathieu <[hidden email]> wrote:
>
> But crucially, what *is* the policy around Cabal versions? This
> comment, https://ghc.haskell.org/trac/ghc/ticket/14558#comment:23
> claims "if Stack doesn't support the version of Cabal that ships with
> a certain version of GHC, it shouldn't claim that it supports that
> version of GHC. The same applies to cabal-install". Is any build tool
> linked against Cabal-X by definition "not a supported configuration"
> by GHC-Z if it ships with Cabal-Y such that X < Y?

My understanding is that this is the general thought, yes. In fact,
I've been told that even though cabal-install 1.24 did end up working
with the GHC 8.2.x series, the release notes, which were not updated
properly, actually _were supposed_ to say cabal-install 2.0.0.0 was
what was supported there. I believe future cabal-installs will warn
when used with a ghc with a newer Cabal-lib than they were built
against...

> Right. But switching from Cabal-2 to Cabal-3 (a hypothetical at this
> point) sounds like a whole new set of features transitively just made
> it into the compiler. Is that something we're happy to happen during
> feature freeze?

Right. After freeze, the compiler itself shouldn't switch from Cabal-2
to Cabal-3. But I would imagine rather that the Cabal-3 tree and the
compiler tree would be updated in tandem, and then the "freeze" would
sort of apply to both in tandem as well. So there wouldn't be big
changes after the freeze, but nor would the compiler be coupled to a
_released_ lib. Rather, they would develop together, freeze together,
and release together.

> I don't disagree. But then we'd need to abandon any notion that
> versions of packages on Hackage and versions of packages in the GHC
> release tarball always match up. Might even be worth calling that out
> explicitly in the policy.

Not exactly. The tarball of the package on hackage should match the
release tarball. Revisions don't change the tarball. They just add
additional metadata to the index as well that cabal-install knows how
to use in conjunction with the tarball:
https://github.com/haskell-infra/hackage-trustees/blob/master/revisions-information.md#what-are-revisions

--Gershom
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Release policies

Boespflug, Mathieu
Hi Gershom,

thanks for the extra input. So we've confirmed two facts:

* GHC (intended to) ship with only Cabal-2.0 support, but there was a
mistake in the release notes so this was unclear to downstream tooling
authors.
* Cabal-2.0 was released anywhere between slightly *after* and
*exactly at the same as* GHC, despite GHC itself shipping with
Cabal-2.0.

I'm not too concerned by the first point: so long as Cabal-X does not
introduce breaking changes, the fact that GHC-Y ultimately shipped
with Cabal-X shouldn't be a problem. And this kind of bug in the
release notes should go away provided more automation.

The second one is more interesting. It is, as you point out, a product
of GHC and Cabal being intimately linked and co-developed to a large
extent. This leads to a simultaneous release that poses a concrete
problem:

* if new Cabal versions are used immediately in GHC, then that gives
no time at all ahead of a GHC release for downstream tooling authors
to adapt, because Cabal is, up until the point of the GHC release, a
moving target.

Three possible solutions:

* Provided no API breaking changes in Cabal, if no metadata that ships
with GHC uses new Cabal features for some period of time before
release, then the problem goes away.
* Or something close to what Manuel proposed in another thread: ship
in GHC-X+1 the Cabal version that was co-developed during the
development cycle of GHC-X.
* Or a middle ground: make feature freeze a thing. Meaning that for a
couple of months before a major GHC release, the major new Cabal isn't
technically released yet, but like GHC itself within this period, it's
pretty staid, so not so much a moving target, and something downstream
tooling authors can possibly adapt to even without any grace period on
new metadata features. This assumes that the 2 months of feature
freeze are enough time for downstream tooling. Thoughts from any of
those maintainers?


On 14 December 2017 at 01:27, Gershom B <[hidden email]> wrote:

> On Wed, Dec 13, 2017 at 7:06 PM, Boespflug, Mathieu <[hidden email]> wrote:
>>
>> But crucially, what *is* the policy around Cabal versions? This
>> comment, https://ghc.haskell.org/trac/ghc/ticket/14558#comment:23
>> claims "if Stack doesn't support the version of Cabal that ships with
>> a certain version of GHC, it shouldn't claim that it supports that
>> version of GHC. The same applies to cabal-install". Is any build tool
>> linked against Cabal-X by definition "not a supported configuration"
>> by GHC-Z if it ships with Cabal-Y such that X < Y?
>
> My understanding is that this is the general thought, yes. In fact,
> I've been told that even though cabal-install 1.24 did end up working
> with the GHC 8.2.x series, the release notes, which were not updated
> properly, actually _were supposed_ to say cabal-install 2.0.0.0 was
> what was supported there. I believe future cabal-installs will warn
> when used with a ghc with a newer Cabal-lib than they were built
> against...
>
>> Right. But switching from Cabal-2 to Cabal-3 (a hypothetical at this
>> point) sounds like a whole new set of features transitively just made
>> it into the compiler. Is that something we're happy to happen during
>> feature freeze?
>
> Right. After freeze, the compiler itself shouldn't switch from Cabal-2
> to Cabal-3. But I would imagine rather that the Cabal-3 tree and the
> compiler tree would be updated in tandem, and then the "freeze" would
> sort of apply to both in tandem as well. So there wouldn't be big
> changes after the freeze, but nor would the compiler be coupled to a
> _released_ lib. Rather, they would develop together, freeze together,
> and release together.
>
>> I don't disagree. But then we'd need to abandon any notion that
>> versions of packages on Hackage and versions of packages in the GHC
>> release tarball always match up. Might even be worth calling that out
>> explicitly in the policy.
>
> Not exactly. The tarball of the package on hackage should match the
> release tarball. Revisions don't change the tarball. They just add
> additional metadata to the index as well that cabal-install knows how
> to use in conjunction with the tarball:
> https://github.com/haskell-infra/hackage-trustees/blob/master/revisions-information.md#what-are-revisions
>
> --Gershom
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Release policies

Ben Gamari-3
In reply to this post by Boespflug, Mathieu
"Boespflug, Mathieu" <[hidden email]> writes:

> Hi Gerhom,
>
> On 14 December 2017 at 00:19, Gershom B <[hidden email]> wrote:
>>
>> Mathieu:
>>
>> I think the points about better tooling for documenting the correct
>> claims in the release process are well taken. Updating the release
>> notes manually leaves way too much room for error.
>>
Indeed, the release notes have historically been a massive headache.
Happily, I wrote a bit of the necessary tooling to fix this a few weeks
ago [1].


[1] e4dc2cd51902a8cd83476f861cf52996e5adf157

>> However, I think you are incorrect that GHC 8.2.1 and 8.2.2 did not
>> have cabal-install 1.24 support. They did. it works with them.
>
> They did, and indeed Stack too worked just fine with them, but that
> was assuming that integer-gmp-1.0.1.0 really was what was shipped in
> the tarballs, not what it was on Hackage (until it got recently
> revised). I don't know which version of integer-gmp-1.0.1.0 was the
> intended one. They both have the same version number and neither seems
> more authoritative than the other to me. Had the Hackage one been the
> one that shipped, then I'm not sure that cabal-install-1.24 would have
> worked. Stack broke the moment what was on Hackage and what was in GHC
> bindists did not line up anymore. And with release notes mentioning
> incorrect version numbers, harder still to tell.
>
I agree that the cabal files uploaded to Hackage should match what is
released or, if not, there should be a very good reason for divergence.

[snip]


>
>> The general motivation of making a "feature freeze" more of a "freeze
>> all the moving parts, really" I do agree with. Having a real freeze is
>> part of a better release process, and it should allow all the
>> downstream consumers of everything more time to really catch up. This
>> is just one instance of that need.
>
> Agreed.
>
Also agreed.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: Fwd: Release policies

Ben Gamari-3
In reply to this post by Boespflug, Mathieu
"Boespflug, Mathieu" <[hidden email]> writes:

> ---------- Forwarded message ----------
> From: Boespflug, Mathieu <[hidden email]>
> Date: 13 December 2017 at 23:03
> Subject: Re: Release policies
> To: Simon Peyton Jones <[hidden email]>
> Cc: [hidden email]
>
>
> [replying to ghc-devops-group@, which I assume based on your email's
> content is the mailing list you intended.]
>
> Hi Simon,
>
> feedback from downstream consumers of Cabal metadata (e.g. build tool
> authors) will be particularly useful for the discussion here. Here are my
> thoughts as a bystander.
>
> It's worth trying to identify what problems came up during the integer-gmp
> incident in Trac #14558:
>
> * GHC 8.2.1 shipped with integer-gmp-1.0.1.0 but the release notes said
> otherwise.
>
> * GHC 8.2.1 shipped with Cabal-2.0.0.2, but specifically claimed in the
> release notes that cabal-install-1.24 (and by implication any other build
> tool based on Cabal-the-library version 1.24) was supported: "GHC 8.2 only
> works with cabal-install version 1.24 or later. Please upgrade if you have
> an older version of cabal-install."
>
> * GHC 8.2.2 also claimed Cabal-1.24 support.
>
> * GHC 8.2.1 was released in July 2017 with Cabal-2.0.0.2, a brand new major
> release with breaking changes to the metadata format, without much lead
> time for downstream tooling authors (like Stack) to adapt.
>
> * But actually if we look at their respective release notes, GHC 8.2.1 was
> relased in July 2017, even though the Cabal website claims that
> Cabal-2.0.0.2 was released in August 2017 (see
> https://www.haskell.org/cabal/download.html). So it looks like GHC didn't
> just not give enough lead time about an upstream dependency it shipped
> with, it shipped with an unreleased version of Cabal!
Perhaps this is true and I admit I wasn't happy about releasing the compiler
without a Cabal release. However, there was no small amount of pressure to
push forward nevertheless as the release was already quite late and the
expectation was a Cabal release would be coming shortly after the GHC
release. Coordination issues like this are a major reason why I think it
would be better if GHC were more decoupled from its dependencies'
upstreams.

I think the approach that we discussed at ICFP, where library
authors must upstream their version bumps before the freeze, just like
any library, is perhaps one way forward although I suspect it exceptions
will need to be made.

> * Libraries that ship with GHC are usually also uploaded to Hackage, to
> make the documentation easily accessible, but integer-gmp-1.0.1.0 was not
> uploaded to Hackage until 4 months after the release.
>
> * The metadata for integer-gmp-1.0.1.0 as uploaded to Hackage differed from
> the metadata that was actually in the source tarball of GHC-8.2.1 and
> GHC-8.2.2.
>
> * The metadata for integer-gmp-1.0.1.0 as uploaded to Hackage included
> Cabal-2.0 specific syntactic sugar, making the metadata unreadable using
> any tooling that did not link against the Cabal-2.0.0.2 library (or any
> later version).
>
> * It so happened that one particular version of one particular downstream
> build tool, Stack, had a bug, compounding the bad effects of the previous
> point. But a new release has now been made, and in any case that's not a
> problem for GHC to solve. So let's keep that out of the discussion here.
>
> So I suggest we discuss ways to eliminate or reduce the likelihood of any
> of the above problems from occurring again. Here are some ideas:
>
> * GHC should never under any circumstance ship with an unreleased version
> of any independently maintained dependency. Cabal is one such dependency.
> This should hold true for anything else. We could just add that policy to
> the Release Policy.
>
We can adopt this as a policy, but doing so very well may mean that GHC
will be subject to schedule slips beyond its control. We can hope that
upstream maintainers will be responsive, but there is little we can do
when they are not. Of course, if we adopt the policy of disallowing all
but essentially core library bumps during the freeze then we may be able
to mitigate this.

> * Stronger still, GHC should not switch to a new major release of a
> dependency at any time during feature freeze ahead of a release. E.g. if
> Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe it's fair
> game to include in GHC. But not if Cabal-3.0.0 hasn't shipped yet.
>
Yes, this I agree with. I think we can be more accomodating of minor
bumps to fix bugs which may come to light during the freeze, but major
releases should be avoided.

> * The 3-release backwards compat rule should apply in all circumstances.
> That means major version bumps of any library GHC ships with, including
> base, should not imply any breaking change in the API's of any such library.
>
I'm not sure I follow what you are suggesting here.

> * GHC does have control over reinstallable packages (like text and
> bytestring): GHC need not ship with the latest versions of these, if indeed
> they introduce breaking changes that would contravene the 3-release policy.
>
> * Note: today, users are effectively tied to whatever version of the
> packages ships with GHC (i.e. the "reinstallable" bit is problematic today
> for various technical reasons). That's why a breaking change in bytestring
> is technically a breaking change in GHC.
>
I don't follow: Only a small fraction of packages, namely those that
explicitly link against the `ghc` library, are tied. Can you clarify
what technical reasons you are referring to here?

> * The current release policy covers API stability, but what about metadata?
> In the extreme, we could say a 3-release policy applies to metadata too.
> Meaning, all metadata shipping with GHC now and in the next 2 releases
> should be parseable by today's version of Cabal and downstream tooling. Is
> such a long lead time necessary? That's for build tool authors to say, and
> a point to negotiate with GHC devs.
>
> * Because there are far fewer consumers of metadata than consumers of say
> base, I think shorter lead time is reasonable. At the other extreme, it
> could even be just the few months during feature freeze.
Right, I wouldn't be opposed to striving for this in principle although
I think we should be aware that breakage is at times necessary and the
policy should accomodate this. I think the important thing is that we be
aware of when we are breaking metadata compatibility and convey this to
our users.

> * The release notes bugs mentioned above and the lack of consistent upload
> to Hackage are a symptom of lack of release automation, I suspect. That's
> how to fix it, but we could also spell out in the Release Policy that GHC
> libraries should all be on Hackage from the day of release.
>
Yes, the hackage uploads have historically been handled manually. I have
and AFAIK most release managers coming before me have generally deferred
this to Herbert as is quite meticulous. However, I think it would be
nice if we could remove the need for human intervention entirely.

> Finally, a question for discussion:
>
> * Hackage allows revising the metadata of an uploaded package even without
> changing the version number. This happens routinely on Hackage today by the
> Hackage trustees. Should this be permitted for packages whose release is
> completely tied to that of GHC itself (like integer-gmp)?
>
If there is a bug in the metadata then I don't think we should
necessarily tie our hands from fixing it. However, we should clearly
take great care when making such changes to avoid further breakage.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: Fwd: Release policies

Boespflug, Mathieu
In reply to this post by Ben Gamari-3
>> On 14 December 2017 at 00:19, Gershom B <[hidden email]> wrote:
>>>
>>> Mathieu:
>>>
>>> I think the points about better tooling for documenting the correct
>>> claims in the release process are well taken. Updating the release
>>> notes manually leaves way too much room for error.
>>>
> Indeed, the release notes have historically been a massive headache.
> Happily, I wrote a bit of the necessary tooling to fix this a few weeks
> ago [1].
>
> [1] e4dc2cd51902a8cd83476f861cf52996e5adf157

Very cool!
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Release policies

Boespflug, Mathieu
In reply to this post by Ben Gamari-3
>> * But actually if we look at their respective release notes, GHC 8.2.1 was
>> relased in July 2017, even though the Cabal website claims that
>> Cabal-2.0.0.2 was released in August 2017 (see
>> https://www.haskell.org/cabal/download.html). So it looks like GHC didn't
>> just not give enough lead time about an upstream dependency it shipped
>> with, it shipped with an unreleased version of Cabal!
>
> Perhaps this is true and I admit I wasn't happy about releasing the compiler
> without a Cabal release. However, there was no small amount of pressure to
> push forward nevertheless as the release was already quite late and the
> expectation was a Cabal release would be coming shortly after the GHC
> release. Coordination issues like this are a major reason why I think it
> would be better if GHC were more decoupled from its dependencies'
> upstreams.

I have the same sentiment. Do you think this is feasible in the case
of Cabal? Even if say something like Backpack shows up all over again?
If so, are there concrete changes that could be made to support the
following workflow:

* upstreams develop their respective libraries independently of GHC
using their own testing.
* If they want GHC to ship a newer version, they create a Diff. As
Manuel proposed in a separate thread, this must be before feature
freeze, unless...
* ... a critical issue is found in the upstream release, in which case
upstream cuts a new release, and submits a Diff again.
* GHC always has the option to back out an offending upgrade, and
revert to a known good version. In fact it should preemptively do so
while waiting for a new release of upstream.
* In general, GHC does not track git commits of upstream dependencies
in an unknown state of quality, but tracks vetted and tested releases
instead.

>> * GHC should never under any circumstance ship with an unreleased version
>> of any independently maintained dependency. Cabal is one such dependency.
>> This should hold true for anything else. We could just add that policy to
>> the Release Policy.
>>
> We can adopt this as a policy, but doing so very well may mean that GHC
> will be subject to schedule slips beyond its control. We can hope that
> upstream maintainers will be responsive, but there is little we can do
> when they are not.

Why not? If GHC only ever tracks upstream releases (as I think it
should), not git commits in unknown state, then we don't need upstream
maintainer responsiveness. Because at any point in time, all GHC
dependencies are already released. If GHC should ship with a newer
version of a dependency, the onus is on the upstream maintainer to
submit a Diff asking GHC to move to the latest version. Are there good
reasons for GHC to track patches not upstreamed and released?

>> * Stronger still, GHC should not switch to a new major release of a
>> dependency at any time during feature freeze ahead of a release. E.g. if
>> Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe it's fair
>> game to include in GHC. But not if Cabal-3.0.0 hasn't shipped yet.
>>
> Yes, this I agree with. I think we can be more accomodating of minor
> bumps to fix bugs which may come to light during the freeze, but major
> releases should be avoided.

Agreed.

>> * The 3-release backwards compat rule should apply in all circumstances.
>> That means major version bumps of any library GHC ships with, including
>> base, should not imply any breaking change in the API's of any such library.
>>
> I'm not sure I follow what you are suggesting here.

Nothing new: just that the 3-release policy doesn't just apply to
base, but also anything else that happens to ship with GHC (including
Cabal). Perhaps that already the policy?

>> * GHC does have control over reinstallable packages (like text and
>> bytestring): GHC need not ship with the latest versions of these, if indeed
>> they introduce breaking changes that would contravene the 3-release policy.
>>
>> * Note: today, users are effectively tied to whatever version of the
>> packages ships with GHC (i.e. the "reinstallable" bit is problematic today
>> for various technical reasons). That's why a breaking change in bytestring
>> is technically a breaking change in GHC.
>>
> I don't follow: Only a small fraction of packages, namely those that
> explicitly link against the `ghc` library, are tied. Can you clarify
> what technical reasons you are referring to here?

Builds often fail for strange reasons when both bytestring-0.10.2 and
bytestring-0.10.1 are in scope. Some libraries in a build plan pick up
one version where some pick up another. The situation here might well
be better than it used to be, but at this point in time Stackage works
hard to ensure that in any given package set, there is *exactly one*
version of any package. That's why Stackage aligns versions of core
packages to whatever ships with the GHC version the package set is
based on.

So in this sense, AFAIK a bug in bytestring can't be worked around by
reinstalling bytestring (not in Stackage land): it requires waiting
for the next GHC version that will ship with a new version of
bytestring with that bug fixed. I'm not entirely familiar with all
Stackage details so Michael - please step in if this is incorrect.

>> * Because there are far fewer consumers of metadata than consumers of say
>> base, I think shorter lead time is reasonable. At the other extreme, it
>> could even be just the few months during feature freeze.
>
> Right, I wouldn't be opposed to striving for this in principle although
> I think we should be aware that breakage is at times necessary and the
> policy should accomodate this. I think the important thing is that we be
> aware of when we are breaking metadata compatibility and convey this to
> our users.

That sounds reasonable. But when have we ever needed to use non
backwards compatible metadata ASAP? The integer-gmp example was a case
in point: the Cabal-2.0 feature it was using was merely syntactic
sugar at this point, since no tool *yet* interprets the new constructs
in any special way AFAIK.

>> * The release notes bugs mentioned above and the lack of consistent upload
>> to Hackage are a symptom of lack of release automation, I suspect. That's
>> how to fix it, but we could also spell out in the Release Policy that GHC
>> libraries should all be on Hackage from the day of release.
>>
> Yes, the hackage uploads have historically been handled manually. I have
> and AFAIK most release managers coming before me have generally deferred
> this to Herbert as is quite meticulous. However, I think it would be
> nice if we could remove the need for human intervention entirely.

Indeed. Can be part of the deploy step in the continuous integration pipeline.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Release policies

Michael Snoyman
In reply to this post by Boespflug, Mathieu


On Thu, Dec 14, 2017 at 12:27 PM, Boespflug, Mathieu <[hidden email]> wrote:

[snip]

* Or a middle ground: make feature freeze a thing. Meaning that for a
couple of months before a major GHC release, the major new Cabal isn't
technically released yet, but like GHC itself within this period, it's
pretty staid, so not so much a moving target, and something downstream
tooling authors can possibly adapt to even without any grace period on
new metadata features. This assumes that the 2 months of feature
freeze are enough time for downstream tooling. Thoughts from any of
those maintainers?


Short answer: if there's a clear idea in advance of when this feature freeze is going to happen, I think we can coordinate releases of downstream tooling (Stack being the most important, but stackage-curator playing in as well) so that 2 months is sufficient. I'll talk with the rest of the Stack team to see if there are any concerns.

Longer answer: Stack intentionally avoids depending on the internals of Cabal wherever possible. Instead of calling library functions directly from within Haskell code to perform builds, for example, it interacts with the Setup.hs files over their command line interface.[1] This has two results:

* Stack can usually start using new GHC/Cabal versions without a new Stack release, since it's just shelling out for the actual build
* There's not usually very much code churn needed in Stack to upgrade to a newer Cabal release

This past release was an exception because of all of the changes that landed, both the new cabal grammar to support the ^>= operator (making the old parser incapable of lossily parsing new files) and API changes (I think mostly around Backpack, though there was some code cleanup as well). In particular, the main interface we need from Cabal—the package description data types and parser—changed significantly enough that it took significant effort to upgrade. There were also new features added (like sub libraries and foreign libraries) that weren't immediately supported by the old Stack version, and had to be manually added in.

Tying this up: generally upgrading to a new Cabal release should be fine, and the only concern I'd have is fitting it into a release schedule with Stack. The complications that could slow that down are:

* Changes to the command line interface that Stack uses (hopefully those are exceedingly rare)
* Major overhauls to the Stack-facing API

Michael

[1] This allows for more reproducible builds of older snapshots, insuring that the exact same Cabal library is performing the builds

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Release policies

Boespflug, Mathieu
Thanks for the feedback, Michael.

Manuel, I believe you are also a Cabal-the-library consumer in Haskell For Mac?

Michael, you brought up another problem tangentially related to the
original integer-gmp issue but that was not in my original list
earlier in this thread:

* Cabal-2.0.0 had breaking changes in the API.

This means that by association GHC itself broke BC, because it shipped
with Cabal-2.0, without the usual grace period.

Now, there are far fewer users of Cabal than of base. All, Michael in
his previous email seems to be okay with breaking changes in Cabal
given the conditions he stated (2 months grace period, advance notice
of when the 2 months start). And perhaps this points to the lack of a
need for the regular grace period applying to Cabal. How many other
users of Cabal-the-library are there? In principle, every single
Hackage package out there, which all have a Setup.hs script. Most of
them are trivial, but how many did break because of these API changes?
I for one am pretty happy for Cabal to move fast, but I'm concerned
that these breaking changes happened without any kind of advance
notice. To Simon's original point - there does not to be a clear
policy and a good process surrounding Cabal itself and other GHC
dependencies. So far we discussed mostly metadata changes, not API
changes.

And to be clear, folks did get some (post facto) notice in September:
http://coldwa.st/e/blog/2017-09-09-Cabal-2-0.html. That's helpful, but
I submit that in the future this really should be part of the GHC
release announcement (which happened over a month before that), and in
fact a migration guide circulated before the feature freeze, so
downstream tooling authors can adapt. If this is not possible, then
perhaps it's premature for GHC to include that given Cabal release.
Again, GHC should always have the option to stick to the old Cabal
version until things get ironed out.


On 15 December 2017 at 08:42, Michael Snoyman <[hidden email]> wrote:

>
>
> On Thu, Dec 14, 2017 at 12:27 PM, Boespflug, Mathieu <[hidden email]> wrote:
>
> [snip]
>
>> * Or a middle ground: make feature freeze a thing. Meaning that for a
>> couple of months before a major GHC release, the major new Cabal isn't
>> technically released yet, but like GHC itself within this period, it's
>> pretty staid, so not so much a moving target, and something downstream
>> tooling authors can possibly adapt to even without any grace period on
>> new metadata features. This assumes that the 2 months of feature
>> freeze are enough time for downstream tooling. Thoughts from any of
>> those maintainers?
>>
>
> Short answer: if there's a clear idea in advance of when this feature freeze
> is going to happen, I think we can coordinate releases of downstream tooling
> (Stack being the most important, but stackage-curator playing in as well) so
> that 2 months is sufficient. I'll talk with the rest of the Stack team to
> see if there are any concerns.
>
> Longer answer: Stack intentionally avoids depending on the internals of
> Cabal wherever possible. Instead of calling library functions directly from
> within Haskell code to perform builds, for example, it interacts with the
> Setup.hs files over their command line interface.[1] This has two results:
>
> * Stack can usually start using new GHC/Cabal versions without a new Stack
> release, since it's just shelling out for the actual build
> * There's not usually very much code churn needed in Stack to upgrade to a
> newer Cabal release
>
> This past release was an exception because of all of the changes that
> landed, both the new cabal grammar to support the ^>= operator (making the
> old parser incapable of lossily parsing new files) and API changes (I think
> mostly around Backpack, though there was some code cleanup as well). In
> particular, the main interface we need from Cabal—the package description
> data types and parser—changed significantly enough that it took significant
> effort to upgrade. There were also new features added (like sub libraries
> and foreign libraries) that weren't immediately supported by the old Stack
> version, and had to be manually added in.
>
> Tying this up: generally upgrading to a new Cabal release should be fine,
> and the only concern I'd have is fitting it into a release schedule with
> Stack. The complications that could slow that down are:
>
> * Changes to the command line interface that Stack uses (hopefully those are
> exceedingly rare)
> * Major overhauls to the Stack-facing API
>
> Michael
>
> [1] This allows for more reproducible builds of older snapshots, insuring
> that the exact same Cabal library is performing the builds
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Fwd: Release policies

GHC - devs mailing list
In reply to this post by Boespflug, Mathieu
|  at this point in time Stackage works
|  hard to ensure that in any given package set, there is *exactly one*
|  version of any package. That's why Stackage aligns versions of core
|  packages to whatever ships with the GHC version the package set is
|  based on.

Ah. It follows that if Stackage wants to find a set of packages compatible with GHC-X, then it must pick precisely the version of bytestring that GHC-X depends on.  (I'm assuming here that GHC-X fixes a particular version, even though bytestring is reinstallable?  Certainly, a /distribution/ of GHC-X will do so.)

If meanwhile the bytestring author has decided to use a newer version of .cabal file syntax, then GHC-X is stuck with that.  Or would have to go back to an earlier version of bytestring, for which there might be material disadvantages.

That would make it hard to GHC to guarantee to downstream tools that it doesn't depend on any packages whose .cabal files use new syntax; which is where this thread started.

Hmm.  I wonder if I have understood this correctly.  Perhaps Michael would like to comment?

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:[hidden email]] On Behalf Of
|  Boespflug, Mathieu
|  Sent: 14 December 2017 22:00
|  To: Ben Gamari <[hidden email]>
|  Cc: ghc-devs <[hidden email]>
|  Subject: Re: Fwd: Release policies
|  
|  >> * But actually if we look at their respective release notes, GHC
|  >> 8.2.1 was relased in July 2017, even though the Cabal website
|  claims
|  >> that
|  >> Cabal-2.0.0.2 was released in August 2017 (see
|  >> https://www.haskell.org/cabal/download.html). So it looks like GHC
|  >> didn't just not give enough lead time about an upstream dependency
|  it
|  >> shipped with, it shipped with an unreleased version of Cabal!
|  >
|  > Perhaps this is true and I admit I wasn't happy about releasing the
|  > compiler without a Cabal release. However, there was no small amount
|  > of pressure to push forward nevertheless as the release was already
|  > quite late and the expectation was a Cabal release would be coming
|  > shortly after the GHC release. Coordination issues like this are a
|  > major reason why I think it would be better if GHC were more
|  decoupled from its dependencies'
|  > upstreams.
|  
|  I have the same sentiment. Do you think this is feasible in the case
|  of Cabal? Even if say something like Backpack shows up all over again?
|  If so, are there concrete changes that could be made to support the
|  following workflow:
|  
|  * upstreams develop their respective libraries independently of GHC
|  using their own testing.
|  * If they want GHC to ship a newer version, they create a Diff. As
|  Manuel proposed in a separate thread, this must be before feature
|  freeze, unless...
|  * ... a critical issue is found in the upstream release, in which case
|  upstream cuts a new release, and submits a Diff again.
|  * GHC always has the option to back out an offending upgrade, and
|  revert to a known good version. In fact it should preemptively do so
|  while waiting for a new release of upstream.
|  * In general, GHC does not track git commits of upstream dependencies
|  in an unknown state of quality, but tracks vetted and tested releases
|  instead.
|  
|  >> * GHC should never under any circumstance ship with an unreleased
|  >> version of any independently maintained dependency. Cabal is one
|  such dependency.
|  >> This should hold true for anything else. We could just add that
|  >> policy to the Release Policy.
|  >>
|  > We can adopt this as a policy, but doing so very well may mean that
|  > GHC will be subject to schedule slips beyond its control. We can
|  hope
|  > that upstream maintainers will be responsive, but there is little we
|  > can do when they are not.
|  
|  Why not? If GHC only ever tracks upstream releases (as I think it
|  should), not git commits in unknown state, then we don't need upstream
|  maintainer responsiveness. Because at any point in time, all GHC
|  dependencies are already released. If GHC should ship with a newer
|  version of a dependency, the onus is on the upstream maintainer to
|  submit a Diff asking GHC to move to the latest version. Are there good
|  reasons for GHC to track patches not upstreamed and released?
|  
|  >> * Stronger still, GHC should not switch to a new major release of a
|  >> dependency at any time during feature freeze ahead of a release.
|  E.g.
|  >> if
|  >> Cabal-3.0.0 ships before feature freeze for GHC-9.6, then maybe
|  it's
|  >> fair game to include in GHC. But not if Cabal-3.0.0 hasn't shipped
|  yet.
|  >>
|  > Yes, this I agree with. I think we can be more accomodating of minor
|  > bumps to fix bugs which may come to light during the freeze, but
|  major
|  > releases should be avoided.
|  
|  Agreed.
|  
|  >> * The 3-release backwards compat rule should apply in all
|  circumstances.
|  >> That means major version bumps of any library GHC ships with,
|  >> including base, should not imply any breaking change in the API's
|  of any such library.
|  >>
|  > I'm not sure I follow what you are suggesting here.
|  
|  Nothing new: just that the 3-release policy doesn't just apply to
|  base, but also anything else that happens to ship with GHC (including
|  Cabal). Perhaps that already the policy?
|  
|  >> * GHC does have control over reinstallable packages (like text and
|  >> bytestring): GHC need not ship with the latest versions of these,
|  if
|  >> indeed they introduce breaking changes that would contravene the 3-
|  release policy.
|  >>
|  >> * Note: today, users are effectively tied to whatever version of
|  the
|  >> packages ships with GHC (i.e. the "reinstallable" bit is
|  problematic
|  >> today for various technical reasons). That's why a breaking change
|  in
|  >> bytestring is technically a breaking change in GHC.
|  >>
|  > I don't follow: Only a small fraction of packages, namely those that
|  > explicitly link against the `ghc` library, are tied. Can you clarify
|  > what technical reasons you are referring to here?
|  
|  Builds often fail for strange reasons when both bytestring-0.10.2 and
|  bytestring-0.10.1 are in scope. Some libraries in a build plan pick up
|  one version where some pick up another. The situation here might well
|  be better than it used to be, but at this point in time Stackage works
|  hard to ensure that in any given package set, there is *exactly one*
|  version of any package. That's why Stackage aligns versions of core
|  packages to whatever ships with the GHC version the package set is
|  based on.
|  
|  So in this sense, AFAIK a bug in bytestring can't be worked around by
|  reinstalling bytestring (not in Stackage land): it requires waiting
|  for the next GHC version that will ship with a new version of
|  bytestring with that bug fixed. I'm not entirely familiar with all
|  Stackage details so Michael - please step in if this is incorrect.
|  
|  >> * Because there are far fewer consumers of metadata than consumers
|  of
|  >> say base, I think shorter lead time is reasonable. At the other
|  >> extreme, it could even be just the few months during feature
|  freeze.
|  >
|  > Right, I wouldn't be opposed to striving for this in principle
|  > although I think we should be aware that breakage is at times
|  > necessary and the policy should accomodate this. I think the
|  important
|  > thing is that we be aware of when we are breaking metadata
|  > compatibility and convey this to our users.
|  
|  That sounds reasonable. But when have we ever needed to use non
|  backwards compatible metadata ASAP? The integer-gmp example was a case
|  in point: the Cabal-2.0 feature it was using was merely syntactic
|  sugar at this point, since no tool *yet* interprets the new constructs
|  in any special way AFAIK.
|  
|  >> * The release notes bugs mentioned above and the lack of consistent
|  >> upload to Hackage are a symptom of lack of release automation, I
|  >> suspect. That's how to fix it, but we could also spell out in the
|  >> Release Policy that GHC libraries should all be on Hackage from the
|  day of release.
|  >>
|  > Yes, the hackage uploads have historically been handled manually. I
|  > have and AFAIK most release managers coming before me have generally
|  > deferred this to Herbert as is quite meticulous. However, I think it
|  > would be nice if we could remove the need for human intervention
|  entirely.
|  
|  Indeed. Can be part of the deploy step in the continuous integration
|  pipeline.
|  _______________________________________________
|  ghc-devs mailing list
|  [hidden email]
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=04%7C01%7Csimonpj%40microsoft.com%7Cc036e34b7c204915be3708d5
|  433e1bc5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364888564139091
|  21%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
|  6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=JifR49MJxw8tGDXFCmZJcNy8yd4KQyM9upeRQPIL9TI%3D&reserved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] Fwd: Release policies

Mikhail Glushenkov
In reply to this post by Boespflug, Mathieu
Hi Mathieu,

On 15 December 2017 at 08:41, Boespflug, Mathieu <[hidden email]> wrote:
> How many other
> users of Cabal-the-library are there? In principle, every single
> Hackage package out there, which all have a Setup.hs script.

This is not such a big deal now, because build-type: Custom packages
can declare the dependencies of the Setup script via the custom-setup
stanza. By default (when there's no custom-setup stanza), Cabal < 2 is
chosen.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] Fwd: Release policies

Mikhail Glushenkov
In reply to this post by Boespflug, Mathieu
Hi Mathieu,

On 15 December 2017 at 08:41, Boespflug, Mathieu <[hidden email]> wrote:
> In principle, every single
> Hackage package out there, which all have a Setup.hs script.

Also, the build-type: Simple packages (which are the vast majority on
Hackage) are not affected at all, because they all use a default
built-in setup script.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Release policies

Michael Snoyman
In reply to this post by GHC - devs mailing list


On Fri, Dec 15, 2017 at 12:10 PM, Simon Peyton Jones via ghc-devs <[hidden email]> wrote:
|  at this point in time Stackage works
|  hard to ensure that in any given package set, there is *exactly one*
|  version of any package. That's why Stackage aligns versions of core
|  packages to whatever ships with the GHC version the package set is
|  based on.

Ah. It follows that if Stackage wants to find a set of packages compatible with GHC-X, then it must pick precisely the version of bytestring that GHC-X depends on.  (I'm assuming here that GHC-X fixes a particular version, even though bytestring is reinstallable?  Certainly, a /distribution/ of GHC-X will do so.)

If meanwhile the bytestring author has decided to use a newer version of .cabal file syntax, then GHC-X is stuck with that.  Or would have to go back to an earlier version of bytestring, for which there might be material disadvantages.

That would make it hard to GHC to guarantee to downstream tools that it doesn't depend on any packages whose .cabal files use new syntax; which is where this thread started.

Hmm.  I wonder if I have understood this correctly.  Perhaps Michael would like to comment?



Stackage does in fact pin snapshots down to precisely one version of each package. And in the case of non-reinstallable packages, it ensures that those package's transitive dependency set are pinned to the same version that ships with GHC. I know there's work around making more package reinstallable, and the ghc package itself may have crossed that line now, but for the moment Stackage assumes that the ghc package and all its dependencies are non-reinstallable. Therefore bytestring, process, containers, transformers, and many more will be pinned in a Stackage snapshot.

Michael

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Fwd: Release policies

GHC - devs mailing list

Therefore bytestring, process, containers, transformers, and many more will be pinned in a Stackage snapshot.

So that would make it significantly harder, even impossible, for GHC releases to make any promises about the .cabal-file format of these packages, wouldn’t it?

 

So even if we made some back-compat promise for non-reinstallable things like integer-gmp or base, we could not do so for bytestring.

 

Does that give you cause for concern?   After all, it’s where Trac #14558 started.  I don’t see how we can avoid the original problem, since we don’t have control over the .cabal file format used by the authors of the packages on which we depend.

 

Still: GHC can only depend on a package P if the version X of Cabal that GHC is using can parse P.cabal.  So if we fix Cabal-X some while in advance and announce that, perhaps that would serve the purpose?  

 

Simon

 

From: Michael Snoyman [mailto:[hidden email]]
Sent: 15 December 2017 09:27
To: Simon Peyton Jones <[hidden email]>
Cc: Boespflug, Mathieu <[hidden email]>; Ben Gamari <[hidden email]>; ghc-devs <[hidden email]>
Subject: Re: Fwd: Release policies

 

 

 

On Fri, Dec 15, 2017 at 12:10 PM, Simon Peyton Jones via ghc-devs <[hidden email]> wrote:

|  at this point in time Stackage works
|  hard to ensure that in any given package set, there is *exactly one*
|  version of any package. That's why Stackage aligns versions of core
|  packages to whatever ships with the GHC version the package set is
|  based on.

Ah. It follows that if Stackage wants to find a set of packages compatible with GHC-X, then it must pick precisely the version of bytestring that GHC-X depends on.  (I'm assuming here that GHC-X fixes a particular version, even though bytestring is reinstallable?  Certainly, a /distribution/ of GHC-X will do so.)

If meanwhile the bytestring author has decided to use a newer version of .cabal file syntax, then GHC-X is stuck with that.  Or would have to go back to an earlier version of bytestring, for which there might be material disadvantages.

That would make it hard to GHC to guarantee to downstream tools that it doesn't depend on any packages whose .cabal files use new syntax; which is where this thread started.

Hmm.  I wonder if I have understood this correctly.  Perhaps Michael would like to comment?

 

Stackage does in fact pin snapshots down to precisely one version of each package. And in the case of non-reinstallable packages, it ensures that those package's transitive dependency set are pinned to the same version that ships with GHC. I know there's work around making more package reinstallable, and the ghc package itself may have crossed that line now, but for the moment Stackage assumes that the ghc package and all its dependencies are non-reinstallable. Therefore bytestring, process, containers, transformers, and many more will be pinned in a Stackage snapshot.

 

Michael


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: [GHC DevOps Group] Fwd: Release policies

Ben Gamari-3
In reply to this post by Boespflug, Mathieu
"Boespflug, Mathieu" <[hidden email]> writes:

> Thanks for the feedback, Michael.
>
> Manuel, I believe you are also a Cabal-the-library consumer in Haskell For Mac?
>
> Michael, you brought up another problem tangentially related to the
> original integer-gmp issue but that was not in my original list
> earlier in this thread:
>
> * Cabal-2.0.0 had breaking changes in the API.
>
> This means that by association GHC itself broke BC, because it shipped
> with Cabal-2.0, without the usual grace period.
>
I'm a bit confused; by "the usual grace period" do you mean the Core
Library Committee's three release policy? AFAIK this policy only applies
to libraries under CLC control (e.g. those defined in the Report and
perhaps template-haskell). The only other compatibility guarantee that
GHC provides is the "two release policy", which stipulates that GHC
should be bootstrappable with the two most recent major GHC releases.

GHC has never, as far as I am aware, considered major version bumps of
its dependencies to be part of its interface. We perform a major bump of
most libraries with nearly every release [1]. Perhaps I've misunderstood
your statement?

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries/VersionHistory

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: [GHC DevOps Group] Fwd: Release policies

Boespflug, Mathieu
On 15 December 2017 at 16:32, Ben Gamari <[hidden email]> wrote:

> "Boespflug, Mathieu" <[hidden email]> writes:
>
>> Thanks for the feedback, Michael.
>>
>> Manuel, I believe you are also a Cabal-the-library consumer in Haskell For Mac?
>>
>> Michael, you brought up another problem tangentially related to the
>> original integer-gmp issue but that was not in my original list
>> earlier in this thread:
>>
>> * Cabal-2.0.0 had breaking changes in the API.
>>
>> This means that by association GHC itself broke BC, because it shipped
>> with Cabal-2.0, without the usual grace period.
>>
> I'm a bit confused; by "the usual grace period" do you mean the Core
> Library Committee's three release policy?

I did mean that one, yes. That was my question earlier - is Cabal
along with *all* core libraries covered by the CLC's 3-release policy?

The *Core Libraries* Committee (CLC) defines a "core library" as

"Our definition of "core library" is a library that ships with GHC."
(See https://wiki.haskell.org/Library_submissions#The_Libraries)

But indeed, Cabal is not part of the CLC libraries list on that page.
So I'm confused too: a) is Cabal a "core library", b) does that mean
Cabal is bound by the 3-release policy?

> GHC has never, as far as I am aware, considered major version bumps of
> its dependencies to be part of its interface. We perform a major bump of
> most libraries with nearly every release [1].

Yes, and major version bumps are not necessarily BC.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
12