Discussion: GHC 7.10.3 and LTS

[phadej]

Motivation: GHC 7.10.3 is just released. GHC 8.0 will soon enter RC cycle as well, if I understood right.

I guess that nightly will try to migrate to 7.10.3 shortly; but I'm more interested in what happens with LTS lines. I remember some comment that multiple LTS majors could be alive simultaneously. I.e. LTS4 will probably based on GHC-8.0.1, but LTS3 will be still updated for some time, won't it, how long? Are there any concrete plan for this?

A bit related, I'd also like to see LTS-2.23 release.

Related stack issue commercialhaskell/stack#1265. It would solve most of our needs, as we could have patched LTS-2.22 for our needs for example. Unfortunately I don't have time this year to even consider working on that myself :(

[ndmitchell]

After GHC 8 comes out, it would be a shame to freeze the major versions of everything in Stackage for people using GHC 7.10. An alternatively would be to have two nightlies, one targeting GHC 8.0 and one targeting 7.10. To reduce the work, you could imagine a rule that GHC 8.0 must be a superset of packages, and all versions must be the same between the two nightly snapshots.

[bergmark]

Related stack issue commercialhaskell/stack#1265. It would solve most of our needs, as we could have patched LTS-2.22 for our needs for example.

How about making a custom snapshot based on LTS-2.22? That's basically what we've done at Silk. We then upgrade it every month. We are also using GHC-7.8 but we also allow new major versions keeping us closer to nightly.

Our instructions for bumping the snapshot:

• First, change the resolver in stack.yaml to ghc-7.8.
• Now you can run diff -u silk-snapshot.yaml <(stack solver 2>&1) to see package additions and removals. If you still have stack 0.1.3, it doesn't enable tests and benchmarks yet, so don't remove dependencies this way since they might be needed for the tests.

For all packages in the diff that can be upgraded, update the snapshot yaml. Then, in the stack.yaml, change the snapshot name (bump the month, probably) since snapshots shouldn't be changed.

I find this process takes very little time, something like an hour a month.

[phadej]

@bergmark yes, some tooling to decide what to upgrade is still needed, but I just hope that stackage and stack tooling will at some point do it for me. E.g. take a custom snapshot, my-shot-2.42.yaml, say "minor bump", and as result you'd have my-shot-2.43.yaml.

With sufficient tooling around custom snapshots, our private developments could be almost independent of the official Stackage snapshots. Almost, because we'd probably continue to base them on Stackage snapshots, and bump versions of packages in our transitive closure only.

But as said, I have no time to do that right now. But would like to help, eventually, if someone else finds this kind of tooling valuable too.

[snoyberg]

To answer some various questions:

• We should move Nightly to GHC 7.10.3 pretty quickly I hope, with some possible casualties due to changes in GHC
• We've always allowed minor version bumps in GHC during an LTS Haskell major version. So, for example, LTS 3.18 could move to 7.10.3. Whether that's feasible depends on whether packages will actually build with it or not
• Stack allows building with newer point releases of GHC than what the LTS itself was built with, see: http://docs.haskellstack.org/en/stable/yaml_configuration.html#compiler-check

While we could theoretically continue running old LTS releases, we've never done so, and unless there's strong reason, I doubt we will. I definitely don't want to start running multiple Nightlies simultaneously: we did that in the past, and it created lots of confusion and difficulty for package authors.

[ndmitchell]

Could you elaborate on the reason for not running multiple Nightlies simultaneously? Were the confusions fundamental, or an issue in the particular policy that time or mindshare at that point?

With my $WORK hat on what I'd really like is nightlies for GHC 7.8, 7.10 and 8.0. That way we can pick the GHC upgrade point while keeping the non-GHC libraries mostly constant. This is effectively what we've done in the past, but manually - first upgrade all packages, then separately upgrade GHC.

[DanBurton]

Personally I'd like to see:

• nightlies on 7.10.3 asap
• lts-4.0 basically as soon as we've resolved issues with nightlies on 7.10.3, and we've resolved any other important blockers (Aeson?). I think 7.10 merits one more major LTS release which gives nightlies some time to start sorting out issues with 8.0
• nightlies on 8.0 release candidates once LTS-4.0 is cut. This point is probably controversial so I'm not setting my heart on it.

[snoyberg]

Could you elaborate on the reason for not running multiple Nightlies simultaneously? Were the confusions fundamental, or an issue in the particular policy that time or mindshare at that point?

There's no meaning to "nightly-2015-12-09" anymore, you have to clarify "the nightly from that date using that GHC version." That was the biggest user-facing confusion. I think the author-facing frustration is well understood.

I think if you work through the various trade-offs long enough, you'll end up pretty close to what LTS Haskell provides.

[ndmitchell]

Yes, you would need to name them ghc-7.10-2015-10-10. Working through the trade offs I arrived at ditch LTS entirely and have only nightly. At the moment there is no GHC 7.8 with the latest version of all packages. That's what I really want for work (for home, I barely care at all - packdeps + Travis sorts it all out).

Of course, you have more practice at this than me, so I may just be misguided.

[DanBurton]

At the moment there is no GHC 7.8 with the latest version of all packages.

It sounds like @bergmark is periodically creating the "snapshots" you seek already. Perhaps we should publish these and update stack to accept resolver strings like berg-2015-12-08?

[juhp]

I think it would be good if we could continue updating more than one LTS release (maybe monthly for older releases).

I think I agree with Dan that bumping lts for ghc-7.10.3 probably makes sense.
I don't think we should move Nightly to ghc-8.0 until it is released.

In the long term it would be nice to have a Nightly Stackage "ghc matrix" but I agree with Michael that it would be too complicated and too much work for everyone now without more automation.
(Maybe someone wants to try and build Nightly with ghc-7.8.4 and see what breaks?)
Supporting more than one version of ghc for nightly is a lot more work and building: so I would suggest doing that weekly/biweekly or monthly.

[ndmitchell]

It sounds like @bergmark is already doing the GHC 7.8.4 nightly snapshots (at a lower frequency)? Having older nightlies be weekly would be fine, and still very useful. (In fact, having normal nightlies be only weekly would be fine, as long as you managed to spot constraint breakages before then.)

[bergmark]

It sounds like @bergmark is periodically creating the "snapshots" you seek already. Perhaps we should publish these and update stack to accept resolver strings like berg-2015-12-08?

It would be of little use to share our snapshots as-is since we sometimes hold back package upgrades because we don't feel like updating all our code yet or a combination of packages cause segfaults because one of them is using manually implemented reference counting in C ;-) We've also removed a lot of packages we don't use.

How about doing a ~weekly build for 7.8 and upper bounding packages that drop 7.8 support or removing them if they prevent newer versions of other packages? This way stackage curators would not have to report every issue. This is a type of snapshot I could see us using.

The tradeoff here is that we would get newer versions of packages but packages could be removed.

[phadej]

@bergmark yes, I could imagine a new subsection in build-constraints.yaml, e.g. skipped-ghc-7.8 as we have skipped-tests etc.

[phadej]

Bump.

Now as LTS4 is released, will LTS3 be still updated for some time?

[DanBurton]

As I understand it, the tech is in place so that updating LTS 3 is possible. I don't think we're promising any more updates to LTS 3, but it could happen.

[snoyberg]

Yup, correct. I'm planning on kicking the tires to ensure it all works, so
there should be at least one more lts 3

On Wed, Jan 6, 2016, 9:52 PM Dan Burton notifications@github.com wrote:

As I understand it, the tech is in place so that updating LTS 3 is
possible. I don't think we're promising any more updates to LTS 3, but
it could happen.

—
Reply to this email directly or view it on GitHub
#1029 (comment).