Proposal: twice as frequent LTS and stable timeline

[domenkozar]

Note: this discussion originally took place at https://gitter.im/commercialhaskell/stackage

The motivation (observations)

a) For a stable release timeline of LTS, the motivation is to set better expectations to maintainers when to pay attention and meet deadlines. At this very moment (based on my experience, others can chip in), getting packages into nightly and orchestrating software releases used by many (eg. Servant) is not easy (especially it's July and people can easily go 3 weeks on vacations so they might miss 2 week pre-announcement). This observation assumes that it's in the interest of stackage curators to get everyone's attention to upcoming LTS and participate in curation.

b) For twice-as-frequent LTS release we can use real-world data for an argument:

• 2018/02/09: Servant-0.13 released
• 2018/03/12: LTS-11 released
• 2018/06/19: Servant-0.14 released
• 2018/07/09: LTS-12 released

There's a roughly half-year release cycle for LTS and Servant follows that. I'm sure many other packages as well. Why would major Servant bump happen in-between if it wasn't included into stackage, forcing maintainers to support sets of packages for stackage LTS and some extra major releases? Half a year release cycle for GHC makes sense, but it's a bit long for a library.

The proposal

a) Pin down LTS release dates, given that LTS-12 came out a month before GHC 8.6, LTS could just be aligned to GHC release date, but lag one release behind. For example, once GHC 8.8.1 comes out, LTS-13 would ship with 8.6.3. Luckily this is easy as GHC already has a stable timeline.

b) Have two LTS releases per GHC: one that makes all packages compatible with new GHC release and another one after 3 months that bumps major versions of libraries

Final words

Note that this is not a strong opinion, but suggestions based on my personal observations. Chip in to agree or disagree.

[fosskers]

Having (b) would be nice. There's precedent for having multiple LTSs per GHC, a la 8 -> 9 and 10 -> 11.

[DanBurton]

A mere 3 months is a very short amount of time to call "long term support". If anything, I'd like us to be able to consider longer windows of support.

However, 6 months seems a long time to wait between ghc release and its inclusion in an LTS.

I'm inclined to maintain flexibility in when we release a new LTS series.

[juhp]

This table of LTS release dates may be a useful reference: currently our LTS releases are on average about 4-5 months apart but quite some variance.

I understand that some people/projects want to move faster, on the other hand for the stability of the wider ecosystem I personally feel (a) is better: three month cycles are actually really fast for big projects like distros (and I also think of Stackage as a Haskell distro). After bumping Nightly to a new major ghc release it also takes a good while for the total number of packages to recover and return to nightly. 6 months may be a long time to wait but during that period Nightly snapshots are available with the latest and greatest for those that want more speed (while no-one is forced to track Nightly day by day, everyone is free to decide which Stackage snapshot to use for their projects and decide when to move from one snapshot to another). I agree that having a predictable release cycle for Stackage LTS should make it easier for package maintainers to plan their own, and it seems to make the most sense to align that around the ghc major release.

I'd like to hear the thoughts from more people.

[cdornan]

I think co-ordinating LTS releases around GHC releases makes sense, 3 months seems much too short (for reasons Jens explains above).

[juhp]

Any more thoughts or feedback here?

I added columns to https://github.com/commercialhaskell/stackage/wiki/Stackage-LTS-Releases with GHC major release dates and our lag with respect to them. (It might be interesting to add the first nightly too but I think that is less informative as we have been reasonably proactive in adopting latest ghc in nightly).

I don't really think we can shorten our cycles more (actually lts-13 was the shortest major release lag ever if I am not mistaken.)

Personally I wouldn't mind trying to align our major releases off ghc major releases (to avoid possible earlier confusion - by aligning I don't mean shortening our delay after GHC major releases, but rather fixing the lag, eg to 4 months for example - to set expectations for the ecosystem).

[DanBurton]

There are several goals which I think are worth aiming for.

• Shorten lag time from ghc release to a corresponding LTS release
• A minimum support window for each LTS
• Longer support windows for some LTS
• A more predictable schedule for LTS releases

There are a few questions that are also worth mentioning:

• Are we willing to upgrade a ghc minor version mid-LTS? (yes)
• Are we willing to support multiple LTS versions at the same time? (yes?)

The above goals conflict with each other. In my opinion, the only way to accomplish them all is if we are willing to start supporting more than 1 LTS at a time. I would like to propose the following schedule for consideration:

• an odd-numbered* LTS is released at most 2 months after a GHC release. This LTS is supported for at least 3 months
• an even-numbered* LTS is released at most 5 months after a GHC release. This LTS is supported for at least 6 months

*(the odd and even don't really matter and are interchangeable)

month 0 GHC release "G.0" 1 2 odd-numbered LTS release "L+1" with G.0 (supported 3 months) 3 4 5 even-numbered LTS "L+2" release with G.0 (supported 6 months), support for L+1 ends

6 GHC release "G.2" 7 8 odd-numbered LTS release "L+3" supporting G.2 (supported 3 months) 9 10 11 even-numbered LTS "L+4" release with G.2, support for L+2 and L+3 ends

12 GHC release "G.4" 13 ... etc

In this conceptualization of LTS releases:

• there will always be exactly 1 longer-running LTS "L" rolling at all times.
• 1/2 of the time (the final 3 months of each longer-running LTS's lifecycle) there will also be a shorter-running LTS "L+1" which supports a newer version of GHC than L
  • these "short lag, short maintenance window" LTS releases should be considered less critical, and it should be ok for them to have fewer packages. It's the LTS for "early adopters" of the new GHC. However, I still hope that enough of the ecosystem can keep pace with these releases so that they are usable for most use cases.
• no LTS is expected to keep supporting a GHC that is 2 or more major releases behind the latest.

In order to support 2 concurrent LTS releases:

• we may wish to enlist more curators, or at least have 2 curators working on separate LTS releases on the same weekend (e.g. if your week starts on Monday, then you also work on one of the LTS releases the weekend prior)
• we may wish to use two separate build machines so that these can be built concurrently

And, to be clear, rather than sticking to "LTS releases are fixed on a 6 month rotating schedule", I think we should instead advertise "LTS releases are fixed on a schedule relative to GHC releases", just in case GHC is... less than predictable about its schedule.

[DanBurton]

With regards to my proposal, in order to support 2 concurrent LTS releases, as an alternative to the above suggestions:

• we may wish to slow the rate of LTS releases to every other week during the "concurrent" period, and alternate between the two every week.

[juhp]

For better or worse I don't see any change coming to this any time soon. At least not without considerable improvements to our project tooling and resources. So I am going to close this out for now - but we can certainly revisit this again in the future, and thank you for the discussion.

[domenkozar]

Since then frequency of releases has turned worse (it has been 9 months since last major GHC bump) and nixpkgs now uses stackage nightly to avoid maintenance hurdles.

How can we help to speed this up?

[juhp]

We are still hoping/waiting for ghc-8.10.3 for LTS17.

Having said that, Fedora will likely also ship Nightly in F34 at this rate.