Ara Adkins writes:

Heya,

I very much agree with the thoughts on the variability of the release cadence. The following is somewhat of a stream of consciousness as I read, so please excuse any lack of coherence.

When you talk about the bugs being significant blockers to the latest release I feel like that kind of issue isn't necessarily touched by moving to a shorter release cadence. In fact if we're unwilling to let certain fixes wait a release then it exacerbates the risk of slowing down a release. I'm not really sure what to do about this, other than adopting the mentality that fixes might not make the major release and will have to come in a point upgrade if they can't be merged to the release branch in time.

You are to some extent correct; an unwillingness to release before major (for some definition of "major") bugs are fixed will inevitably lead to slips. However, I think a faster release cycle will make it easier to accept releases with such bugs (at least in the case of non-regressions).

Regarding the benefits of an abbreviated release cycle, we see it quite a lot in the rust community. There's a good amount of community involvement with the new releases, and new features are hotly anticipated as they often occur on a timescale where the enthusiasm is still there. I also feel, though this is purely anecdotal, that the more agile release schedule encourages community contributions as the tangible benefits of contributor work can be realised much more quickly. The number of RFCs in discussion at the moment is evidence of that, I feel.

It's not all sunny, however, as having so many rapid releases means that it's sometimes difficult to rally the community around certain releases and feature sets. This is perhaps less of an issue due to the maturity of GHC and its ecosystem, but, like you say, it's important to find a good trade-off between release cadence and stability.

Personally, I think Rust's cadence is a touch too short. On a related note, there's a 'checkpoints' initiative to build rallying releases that represent significant milestones in development [1]. This is, however, also tied into Rust's stability story, so only parts of it are relevant to GHC.

I agree that Rust is a bit extreme. Even with ideal tooling I don't think that GHC could manage the cadence maintained by Rust, nor do I think we should. The language is simply at a much different point in its evolution. Their strong adherence to stability certainly also helps.

In terms of automated tooling, I think there is significant benefit from it. Again, using rust as an example, there is cargobomb [2], a significant automated testing initiative that both combines packages on Cargo, and runs their test suites. I feel that a combination of the Stackage LTS and Nightly releases would provide a well-curated subset of Hackage that could possibly be used in a similar fashion. This hits on your item (b).

Regarding your questions: - In comparison to rust it can feel like there's significant delay in being able to really use GHC's newest features. I feel like this delay can hinder adoption of the features as much of the enthusiasm for them has died down by the time they're properly available.

This seems to be a pretty widely held belief. It is very helpful to hear this clearly articulated.

- With the advent of tools such as `stack`, the compiler upgrade process has almost become trivial. While not everyone uses it, it requires no more work than upgrading to a new LTS release and running `stack setup`. Nevertheless, I could imagine four upgrades a year still being okay if it was manual.

Indeed tools have improved remarkably in the Haskell community over the past few years. However, I feel like a word like "trivial" may be a bit strong here. Afterall, library authors still need to follow changes in core libraries (e.g. template-haskell, ghc-prim, and ghc itself). This does require effort, although perhaps on the part of a smaller number of people.

- The three release policy is an interesting case as the question of changing it really comes down to how we view the GHC stability story. Personally, I think we want to target a time-period of stability, rather than a number of releases. Whether that time period is 1.5 years (assuming a six-month release cadence), or 3 years (rounding the current release cadence) seems like a totally independent discussion to me.

This makes sense.

- I think I've covered incentives to contribute in my discussion of Rust above.

I hope that's useful!

Indeed it is. Thanks for taking the time to share! Cheers, - Ben

On 2017-08-01 15:05, Ara Adkins wrote:

Heya,

I very much agree with the thoughts on the variability of the release cadence. The following is somewhat of a stream of consciousness as I read, so please excuse any lack of coherence.

When you talk about the bugs being significant blockers to the latest release I feel like that kind of issue isn't necessarily touched by moving to a shorter release cadence. In fact if we're unwilling to let certain fixes wait a release then it exacerbates the risk of slowing down a release. I'm not really sure what to do about this, other than adopting the mentality that fixes might not make the major release and will have to come in a point upgrade if they can't be merged to the release branch in time.

Regarding the benefits of an abbreviated release cycle, we see it quite a lot in the rust community. There's a good amount of community involvement with the new releases, and new features are hotly anticipated as they often occur on a timescale where the enthusiasm is still there. I also feel, though this is purely anecdotal, that the more agile release schedule encourages community contributions as the tangible benefits of contributor work can be realised much more quickly. The number of RFCs in discussion at the moment is evidence of that, I feel.

(Sorry, this is also kind of a braindump.) I'd like to add a few thoughs (or just to underscore the ones you've already brought forth, as the case may be): - In the case of e.g. the Linux kernel, there's a pretty good assurance that *someone* will maintain a "stable" release of a reasonably-recent version of the kernel and backport(!) patches for, say, up to a year (either distros or the 'stable' kernel maintainer & co). In the case of the Linux kernel backporting will *usually* not be that much work, but in the case of GHC it *might* be a lot more work for any number of reasons -- I wouldn't presume to know. Also note that this is *basically* how Rust also works, it's just that they keep the "unstable" bits behind a feature flag (until they're deemed 'stable') instead of actually having different code bases. - Releasing often means that *all* the upstreams who care(!) get to "start" early as well. (RCs notwithstanding) See e.g. Stackage. - Releasing often means that any serious bugs that get into a release can also get a *release* that fixes them ASAP (and this is important:) *independent* of any other release-blocking bugs in *upcoming* features. This is a Big Deal(TM) and I think it's why the Linux kernel model works at all. - Releasing often means that there isn't this absolutely mad rush to get $YOUR_FEATURE in before the deadline, because what's another 3/6 months in the grand scheme of things? When you don't know if $FEATURE will make it in in ½ year or 2 years, then it's a problem -- and you rush like mad (likely making miskakes in the process). - As a corollary to that: It is *paramount* that the release schedule is adhered to *quite* strictly. This is also, I believe, key to its success in the Linux kernel and Rust community. It doesn't matter much if feature "X" makes it in -- it'll be in the next soon-to-come release. - And, yes, this means a serious committment to improving the tooling/automation around GHC releases. Regards,