Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: twice as frequent LTS and stable timeline #143
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:
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.
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
Note that this is not a strong opinion, but suggestions based on my personal observations. Chip in to agree or disagree.
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.
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.