
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Heya,</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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). </div><div><br></div><div>Regarding your questions:</div><div><div>- 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. </div></div><div>- 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. </div><div>- 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. </div><div>- I think I've covered incentives to contribute in my discussion of Rust above. </div><div><br></div><div>I hope that's useful! </div><div><br></div><div>Best,<br><div>_ara</div></div><div><br></div><div>[1] <a href="https://github.com/rust-lang/rfcs/pull/2052">https://github.com/rust-lang/rfcs/pull/2052</a></div><div>[2] <a href="https://github.com/rust-lang-nursery/cargobomb">https://github.com/rust-lang-nursery/cargobomb</a></div><div><br>On 1 Aug 2017, at 03:19, Ben Gamari <<a href="mailto:ben@well-typed.com">ben@well-typed.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span><br><span>Hello everyone,</span><br><span></span><br><span>I just posted a pair of posts on the GHC blog [1,2] laying out some</span><br><span>thoughts on the GHC release cycle timing [1] and how this relates to the</span><br><span>in-progress Jenkins build infrastructure [2]. When you have a some time</span><br><span>feel free to give them a read and comment (either here or on the Reddit</span><br><span>thread [3]).</span><br><span></span><br><span>Cheers,</span><br><span></span><br><span>- Ben</span><br><span></span><br><span></span><br><span>[1] <a href="https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule">https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule</a></span><br><span>[2] <a href="https://ghc.haskell.org/trac/ghc/blog/jenkins-ci">https://ghc.haskell.org/trac/ghc/blog/jenkins-ci</a></span><br><span>[3] <a href="https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_ghcs_release_schedule/">https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_ghcs_release_schedule/</a></span><br></div></blockquote></body></html>