Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a new document about support policies in readthedocs #8108

Open
jneira opened this issue Apr 23, 2022 · 2 comments
Open

Create a new document about support policies in readthedocs #8108

jneira opened this issue Apr 23, 2022 · 2 comments
Labels

Comments

@jneira
Copy link
Member

jneira commented Apr 23, 2022

  • Imho support policies are important enpugh to give it more relevance
    • Users should have a place to consult it to prepare and plan their migrations
  • We have a note about window support for ghc versions used to build Cabal and cabal-install in a list o points inside contributing.md
      • cabal install cabal-install is a recommended way to upgrade cabal-install so that support would affect even newcomers
  • It could be a generic document about support policies to be able to add other support windows (like which ghcs we support at runtime)

(Moreover i think contributing.md should be also in readthedocs, but it would be another issue)

@jneira jneira added type: enhancement documentation re: readthedocs Concerning hosting documentation on `readthedocs` labels Apr 23, 2022
@andreabedini
Copy link
Collaborator

andreabedini commented May 2, 2022

I had a look at this but I am puzzled (as always). So this comment is just to start a discussion.

In CONTRIBUTING.md, we write:

Our GHC support window is five years for the Cabal library and three years for cabal-install: that is, the Cabal library must be buildable out-of-the-box with the dependencies that shipped with GHC for at least five years.

Which means we support e.g GHC 8.2.1, released on 22nd July 2017, until 22nd July 2012.

But looking at the GHC download page only 9.2.2, 9.0.2 and 8.10.7 are listed as "current". So, basically we are saying we are supporting Cabal on GHC versions than GHC team considers deprecated.

Now, given we specify "that is, the Cabal library must be buildable out-of-the-box with the dependencies that shipped with GHC" this might make sense but I find that statement a bit weak (what if it builds but then it doesn't work?!).

I would consider something supported it the functionality is 100% complete, i.e. all test passes. This might include workarounds for well known bugs in GHC (which is something else that could be discussed).

Also, what about the minor versions? The way it's written at the moment implies we support them all.

I prepared the following table to include in CONTRIBUTING.md. I excluded the minor versions for my own sanity sake.

Cabal currently supports the following GHC versions:

- 9.2.2 (until 5 March 2027)
- 9.0.2 (until 25 December 2026)
- 8.10.7 (until 27 August 2026)
- 8.8.4 (until 15 July 2025)
- 8.6.5 (until 23 April 2024)
- 8.4.4 (until 14 October 2023)
- 8.2.2 (until 22 July 2022)

While cabal-install currently supports:

- 9.2.2 (until 5 March 2025)
- 9.0.2 (until 25 December 2024)
- 8.10.7 (until 27 August 2024)
- 8.8.4 (until 15 July 2023)

@Mikolaj
Copy link
Member

Mikolaj commented May 2, 2022

But looking at the GHC download page only 9.2.2, 9.0.2 and 8.10.7 are listed as "current". So, basically we are saying we are supporting Cabal on GHC versions than GHC team considers deprecated.

Deprecated doesn't mean that big groups of users from, say, a university or a corporation don't use them for whatever reason, e.g., because a distribution has an old version or a corporate approval is not yet given for a new version (e.g., due a C library dependency not having an approval). Yes, they can often use old cabals for old GHCs, but sometimes they need to use an old GHC with new packages that require a new cabal or a new cabal makes a workflow much more comfortable.

Now, given we specify "that is, the Cabal library must be buildable out-of-the-box with the dependencies that shipped with GHC" this might make sense but I find that statement a bit weak (what if it builds but then it doesn't work?!).

I would consider something supported it the functionality is 100% complete, i.e. all test passes.

Agreed. I think the laziest action is to clarify our promise is weak and to point out to the user where in CI scripts the user can check if, in fact, a given mix of cabal version and OS is included or excluded from testing.

This might include workarounds for well known bugs in GHC (which is something else that could be discussed).

IMHO, having limited resources, we should rather focus on cabal in context of the non-deprecated GHCs. Unless somebody desperately needs a fix and is ready to perform most of the fixing and, say, is a huge Haskell sponsor. Then the table is the "let's see if it's easy" area and outside the table it's "good luck and feel free to ask questions".

Also, what about the minor versions? The way it's written at the moment implies we support them all.

IMHO, let's clarify we don't (but with a fine print that cabal may still work, we don't detect and reject minor versions).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants