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

Revise forward/backward compatiblity window for Cabal versions >= 2 #3838

Closed
hvr opened this Issue Sep 13, 2016 · 9 comments

Comments

Projects
None yet
6 participants
@hvr
Copy link
Member

hvr commented Sep 13, 2016

Our policy regarding Cabal appears to be

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

However, given that Cabal is a special case to cabal for custom build-type packages, this compatibility window is too short and results in artificial constraints for install solving. So we should strive to support wide compatibility windows as long as possible in a best effort way, specifically we shouldn't drop support for older GHCs just for mere convenience if there's no well motivated technical reason for doing so.

Quoting @dcoutts from #3833:

There may be a good argument now for us reconsidering and expanding our support window. With the advent of setup-deps we can have a packages that need older versions of Cabal, and conversely using a new cabal-install with an older ghc may sill involve using packages that require a more recent Cabal.

So we may have to expand our support window in both directions: point releases of older Cabal to work with newer ghc, and keeping latest Cabal building with older ghc.

@ezyang ezyang added this to the 2.0 milestone Sep 13, 2016

@ezyang

This comment has been minimized.

Copy link
Contributor

ezyang commented Sep 13, 2016

I'm OK with expanding the window, sticking to GHC 7.4 hasn't caused problems for me.

@ttuegel

This comment has been minimized.

Copy link
Member

ttuegel commented Sep 13, 2016

I have no opinion on the compatibility policy for Cabal. For cabal-install, I favor keeping the current policy; the proposed policy is very restrictive. If we expand the policy for Cabal while keeping the policy the same for cabal-install, that would complicate our CI setup. I think we would need to consider separating the repositories again.

@ttuegel

This comment has been minimized.

Copy link
Member

ttuegel commented Sep 13, 2016

One more thing: I strongly object to any policy that includes soft limits ("best effort") for backwards compatibility. Users need to know exactly what they can expect. Our policy should be absolutely rigid.

@dcoutts

This comment has been minimized.

Copy link
Member

dcoutts commented Sep 13, 2016

@ttuegel I agree about the best effort thing, though I'm guilty of taking that approach in the past.

As for cabal-install's compat vs Cabal, it's quite true that we don't need such wide compatibility for building cabal-install with lots of GHC versions as we might for Cabal. So indeed we would have to look at the CI. I'd prefer not to split the repos however. Wouldn't it "just" be a case of omitting the cabal-install part of the build for certain ghc versions? @hvr how tricky would it be?

@ezyang

This comment has been minimized.

Copy link
Contributor

ezyang commented Sep 13, 2016

That would be easy.

@23Skidoo 23Skidoo self-assigned this Sep 13, 2016

@23Skidoo

This comment has been minimized.

Copy link
Member

23Skidoo commented Sep 13, 2016

I'm on this.

@BardurArantsson

This comment has been minimized.

Copy link
Collaborator

BardurArantsson commented Sep 17, 2016

If ya'll'lll pardon a dumb question... Why is the policy here time-based rather than on number of major releases?

@ezyang

This comment has been minimized.

Copy link
Contributor

ezyang commented Sep 17, 2016

No good reason. Atm it's a major release a year, so I arbitrarily picked years as the postage.

@23Skidoo

This comment has been minimized.

Copy link
Member

23Skidoo commented Sep 17, 2016

If a major release is still getting updates after 1-2 years its support window gets automatically extended when the policy is time-based.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment