I don’t get that. What would that solve? More minor features would be available faster?
Given how absolutely HUGE .stack / .cabal / /nix caches are even with a few active compilers I dread the increased churn of “no, please you MY ghc/stackage version so I can share build results I’ve accumulated by now”.
If everyone would use every damn minor out there I gonna need a 640TB drive to avoid monkeypatching their projects.
Minor releases are supposed to be backward API compatible, no?
If everyone were using the same longer-lived major version (or two) that should reduce the size of required caches overall considerably and the wider maintenance burden of the Haskell community.
Currently I build my projects for every single ghc9 major version as far as possible - it is quite ridiculous.
As I pointed out there have already been 6 releases overall this year and we are not even done yet: we are about to see 9.12.1, and there hasn’t even been a single minor update pushed for 9.10 yet… I think development is stretched over too many major versions for everyone.
(Anyway it’s good you reminded me to run stack-clean-old keep-minor again. :- )
…and since 2024 May 22 (i.e. the last six months)? A thread which seems to defy an mutually-agreeable conclusion.
With a view to the approaching proselytised (northern hemisphere) winter-solstice festivities, here’s one way we can all have some time to perhaps contemplate a better future for Haskell - shut down all the Haskell servers across December (and just have a helpful "back next year!" message to alleviate any confusion). Everyone can then just enjoy their time with the people they care about (and chreekat can have some more time away from “the s**t mines” ), to return with new-year’s energy and enthusiasm and solve this and other ongoing problems!
Yes, but this is not the case.
Only after the base/ghc split has borne fruit can we start assuming some stability between minor versions of base.
There has already been some improvement, at least. The actual breaking changes are happening in ghc-internal, which now gets a major version bump with every (minor) version bump of GHC. Thus it follows PVP. Previously, the breaking changes were in the ghc library, which did not follow PVP.
But base still re-exports (nearly) everything from ghc-internal, so breaking changes in the latter affect the former. But the path to a non-breaking release of GHC is now visible.
It looks like the current status for this process is to wait on @bgamari to make recommendations for deprecating unstable modules.
Just to add to this. Another area that needs some work for the split is tooling support. How will cabal and stack(age) handle this change?
I have a tracking issue (if there are other issues please link them!) for cabal here: Tracking issue: easily reinstallable boot libraries · Issue #10440 · haskell/cabal · GitHub
Hi, I’m interested in contributing directly to GHC for its upcoming release, and I’d love to explore ways to incorporate advanced mathematical or combinatorial techniques into the compiler. Currently studying Master’s in mathematics and computer science, and I’m especially keen on areas where GHC could benefit from optimizations, formal methods, or type-driven improvements that support complex computations or provide enhanced guarantees at compile time.
Additionally, if there are ongoing projects related to combinatorial optimization or type system improvements, I’d love to get involved!
I don’t quite understand what you mean by this.
ghc-internal follows PVP (this was negotiated and agreed on by GHC HQ)ghc-internal is an implementation detail of base… anything that affects base API, no matter where the implementation lives… has to go through a CLC proposalFor the curious, here’s the proposal that encodes the contract between GHC HQ and the CLC: tech-proposals/proposals/accepted/051-ghc-base-libraries.rst at main · haskellfoundation/tech-proposals · GitHub
I think this means we must be careful changing functions in ghc-internal that are re-exported by base because these are subject to the versioning of base. If we introduce a breaking change in ghc-internal (which is OK, because we are very likely to make a major bump in every GHC release), we must also bump the major version of base if that function is re-exported and the change signed off by the CLC. I think that is what Bryan meant.
However, the proposal does not constrain what changes GHC devs do to ghc-internal (which increments majorly all the time). In particular, it does not mean that the API exported by ghc-internal is directly governed by the CLC unless it touches the API of base.
You’re right. I get my terminology mixed up. And I don’t seem to understand the goals of the GHC/base split as well as I thought I did.
I suppose this withdrawn CLC proposal is an example of a positive outcome of the split. Something that would have gone into base, and would have required the full CLC proposal process and the introduction of a breaking change, went into a separate library altogether. So the benefit is that fewer breaking changes go into base, and thus base has less churn. Some day this could mean that the difference of base versions between GHC x.y and GHC x.(y+1) could even just be a minor version.