-
Notifications
You must be signed in to change notification settings - Fork 74
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
Comments
One more thing: doctest's support window is constrained by upstreams, in particular Cabal's:
|
As a hopefully soon to be contributor to
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: We can expect the Haskell Survey to be a bit biased, but I'd be surprised if it differs that much from reality. |
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.
Ubuntu gives 5 years of support to LTSs, so [1] https://packages.ubuntu.com/search?keywords=ghc |
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.
The text was updated successfully, but these errors were encountered: