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

Proposal: twice as frequent LTS and stable timeline #143

Open
domenkozar opened this Issue Jul 10, 2018 · 4 comments

Comments

Projects
None yet
5 participants
@domenkozar
Copy link

domenkozar commented Jul 10, 2018

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

This comment has been minimized.

Copy link

fosskers commented Jul 10, 2018

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

@DanBurton

This comment has been minimized.

Copy link
Contributor

DanBurton commented Jul 11, 2018

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 comment has been minimized.

Copy link
Contributor

juhp commented Jul 20, 2018

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

This comment has been minimized.

Copy link

cdornan commented Oct 21, 2018

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

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