Closed angerman closed 6 years ago
/cc @bgamari
@angerman I'm confused: why is the submodule commit not enough?
If anyone needs the right version of Hadrian for ghc-8.4
branch, they have it exactly there:
Assuming someone wants to make changes to hadrian for a subsequent 8.4 release? Where would those go. The issue with the iserv-split
was that it was only in master and not in 8.4; thus after landing it in master, hadrian was updated, but that meant you couldn't use hardrian head for 8.4 anymore, and subsequently we reverted the iserv-split
in HEAD so hadrian could be reverted in HEAD only so that we could build 8.4 with hadrian again.
As ghc HEAD and hadrian HEAD evolve in symbiosis, we'll need some way to evolve ghc 8.4 and the corresponding hadrian, for subsequent 8.4 releases.
Right, I see, thanks for clarifying! Looks like a branch is the only solution -- feel free to create one, following the GHC naming scheme, i.e. ghc-8.4
.
I don't think I can. I think someone with write rights needs to.
@angerman Done: https://github.com/snowleopard/hadrian/tree/ghc-8.4
Happy to keep creating new branches for upcoming GHC releases -- just ping me.
Now that ghc-8.4 is nearing release. We should to create a branch (or at least tag) that has hadrian corresponding to ghc-8.4.
hadrian in ghc-8.4 is at da39729.
Why do we need this? Any further changes to ghc (e.g. the iserv-split) will require changes to hadrian. When the build system was part of GHC this was trivial, as it was frozen in time in the release branch. It is arguably the same right now with the submodule pinning the hadrian version at da39729 to ghc-8.4.
For consistency I would still suggest to create a ghc-8.4 branch.