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

Bump the default LTS from 11 to 14 #5162

Merged
merged 17 commits into from
Mar 7, 2020
Merged

Bump the default LTS from 11 to 14 #5162

merged 17 commits into from
Mar 7, 2020

Conversation

snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Feb 5, 2020

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:

  • Any changes that could be relevant to users have been recorded in the ChangeLog.md
  • The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

@snoyberg snoyberg requested a review from borsboom February 5, 2020 09:04
@borsboom
Copy link
Contributor

borsboom commented Feb 5, 2020

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 stack-lts-12.yaml is still in place. Is the intent to keep that there to continue supporting GHC 8.4 as well?

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.

@snoyberg
Copy link
Contributor Author

snoyberg commented Feb 5, 2020

so it might be a better idea to run through the whole release process before merging this PR.

Seems reasonable to me.

I see that stack-lts-12.yaml is still in place. Is the intent to keep that there to continue supporting GHC 8.4 as well?

That was my initial thought, but I'm more than happy to drop it instead.

@borsboom
Copy link
Contributor

borsboom commented Feb 7, 2020

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?

@borsboom
Copy link
Contributor

borsboom commented Feb 7, 2020

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.

@snoyberg
Copy link
Contributor Author

snoyberg commented Feb 9, 2020

I think under the circumstances it's reasonable to drop ARMv7 support.

@borsboom borsboom mentioned this pull request Feb 9, 2020
2 tasks
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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

@snoyberg
Copy link
Contributor Author

@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.

@jeffhappily
Copy link
Contributor

No prob, I'll work on it

snoyberg and others added 16 commits March 6, 2020 21:20
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.
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.
@snoyberg snoyberg merged commit 9ae6c81 into master Mar 7, 2020
@snoyberg snoyberg deleted the newer-lts branch March 7, 2020 16:49
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

Successfully merging this pull request may close these issues.

4 participants