Ara Adkins <m...@ara.io> 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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs