-
Notifications
You must be signed in to change notification settings - Fork 702
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
Comments
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:
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.
|
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.
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.
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".
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). |
cabal install cabal-install
is a recommended way to upgrade cabal-install so that support would affect even newcomers(Moreover i think contributing.md should be also in readthedocs, but it would be another issue)
The text was updated successfully, but these errors were encountered: