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

RFC: support window for GHC major versions #284

Open
quasicomputational opened this issue Feb 8, 2021 · 3 comments
Open

RFC: support window for GHC major versions #284

quasicomputational opened this issue Feb 8, 2021 · 3 comments

Comments

@quasicomputational
Copy link
Collaborator

Older GHCs are starting to be a real drag (e.g., #277). doctest is pretty widely-used and can constrain downstream packages' support windows, if they want to test as they fly, so I think it's worth making an effort to keep it pretty wide - but there will be a limit where the juice isn't worth the squeeze. I think a bright line will be better all around than a vague commitment to keeping things working until they stop being worth it.

As a rough first draft, I am thinking of something like 'if a major version of GHC was superseded by another major version more than 3 years ago, it will be dropped', which will hopefully be broad enough to be useful downstream while also bounding the amount of compatbility contortion needed.

@quasicomputational
Copy link
Collaborator Author

One more thing: doctest's support window is constrained by upstreams, in particular Cabal's:

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.

@martijnbastiaan
Copy link

Older GHCs are starting to be a real drag

As a hopefully soon to be contributor to doctest, I'd like to echo that frustration.

As a rough first draft, I am thinking of something like 'if a major version of GHC was superseded by another major version more than 3 years ago, it will be dropped'

IMO the biggest reason for supporting multiple GHC versions is to provide an upgrade path for users lagging behind the newest GHC (for good reasons, of course) - not to provide users on old GHCs with new features. With that in mind, I think a simple rule like "the last n major versions" should work pretty well in practice.

What that n should be is a little bit less clear to me, but I think 5 should be plenty. If the Haskell Survey 2020 is to be believed, this should cover 95%+ of the users:

Selection_315

We can expect the Haskell Survey to be a bit biased, but I'd be surprised if it differs that much from reality.

@andreasabel
Copy link
Collaborator

One parameter for users of Haskell-wrought products that need to be compile from source are the GHC versions shipped with OS LTSs like Ubuntu [1,2]. These could well be 5 years old.

  • xenial (16.04): 7.10.3
  • bionic (18.04): 8.0.2

Ubuntu gives 5 years of support to LTSs, so xenial is still active for two months [2]. (EOL of xenial is in 2024, but I don't think we need to support 7.10.3 until then.)

[1] https://packages.ubuntu.com/search?keywords=ghc
[2] https://wiki.ubuntu.com/Releases

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

No branches or pull requests

3 participants