-
Notifications
You must be signed in to change notification settings - Fork 841
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
Bump the default LTS from 11 to 14 #5162
Conversation
Have all the implications of this, in particular for the release process, been thought through? For example, we'll need to ensure that all platforms we wish to target for binary releases are still supported. There will be a fair amount of adjustment needed to the release process to work with this update. In the past we've tended to do that adjustment after we decide it's time for a release, but that's caused significant delays when problems are discovered, so it might be a better idea to run through the whole release process before merging this PR. I see that The integration tests should all be updated to a matching LTS. Otherwise, every integration test will end up pulling and building the snapshot from scratch, which will greatly increase the amount of time they take. Either that or the integration test framework should be updated to better handle multiple snapshots. |
Seems reasonable to me.
That was my initial thought, but I'm more than happy to drop it instead. |
I'm not sure if this is still the case with the Azure Pipelines CI, but back when CI was done on Travis and others there were also some changes needed to the matrix so that the right GHC version would be pre-installed (especially for the Cabal-based builds). Maybe @psibi can weight in on whether that's necessary here? |
I did a sweep through all the platforms, and it looks GHC 8.6.5 doesn't have any ARMv7 bindists. Are we OK with dropping ARMv7 bindists for the next major Stack release? I do think ARMv7 users appreciate having the bindist, just because it takes so long to build to build from source on that platform. That said, given no recent GHC versions have ARMv7 bindists (GHC 8.4.4 doesn't either), I don't think it would be unreasonable to drop support. |
I think under the circumstances it's reasonable to drop ARMv7 support. |
snapshot.yaml
Outdated
- rio-prettyprint-0.1.0.0@rev:0 | ||
- hi-file-parser-0.1.0.0@rev:0 | ||
- http-download-0.1.0.0@rev:0 | ||
- hpack-0.33.0@rev:0 | ||
- github: snoyberg/filelock |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any hope of someday being able to use the Hackage version of filelock
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've pinged @nh2 about this, hopefully the changes will be merged upstream.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have commented on takano-akio/filelock#7 for some feedback from @takano-akio.
@jeffhappily will you take a stab at resolving the issues with this PR that @borsboom pointed out? Specifically, we need to update the resolvers used by the integration tests to use GHC 8.6.5, or theoretically modify the integration test runner to not require reinstalling GHC each time. |
No prob, I'll work on it |
f140788
to
13882dd
Compare
I'm fairly certain that we would also need to modify the integration tests to use a more recent GHC, but not sure on procedure there.
This should help cache-s3 key the cache correctly to the right version of GHC and avoid running out of disk space.
This reverts commit fbe71c9.
We were getting an error when running the integration tests on Windows due to the presence of a Unicode character in the standard output. From what I can tell, this is actually a bug in Shake's running of processes. By changing over to rawSystem, we bypass that codepath and get to see if that theory is true.
This reverts commit 8f04ad9.
I'm fairly certain that we would also need to modify the integration
tests to use a more recent GHC, but not sure on procedure there.
Note: Documentation fixes for https://docs.haskellstack.org/en/stable/ should target the "stable" branch, not master.
Please include the following checklist in your PR:
Please also shortly describe how you tested your change. Bonus points for added tests!