| ... | ... | @@ -122,4 +122,13 @@ This ensures that commits can only be pushed to `wip/.*`, which the submodule ch |
|
|
|
|
|
|
|
`Haddock` is quite closely tied to GHC. Consequently, there is one `haddock` branch for each GHC major release series (e.g. haddock's `ghc-8.6` for GHC's `ghc-8.6` branch). Meanwhile, GHC's `master` branch follows `haddock`'s `ghc-head` branch.
|
|
|
|
|
|
|
|
Meanwhile, development of `haddock` itself occurs on GHC's current major release branch. This is then periodically merged into `ghc-head`. |
|
|
\ No newline at end of file |
|
|
|
Meanwhile, development of `haddock` itself occurs on GHC's current major release branch. This is then periodically merged into `ghc-head`.
|
|
|
|
|
|
|
|
#### Dealing with haddock changes as ghc dev.
|
|
|
|
|
|
|
|
As ghc dev what this means for you is you need to:
|
|
|
|
|
|
|
|
* Create your patch to haddock such that ghc+haddock both build+work together. Similar to how it's described above.
|
|
|
|
* Open an MR against haddocks ghc-head branch *on gitlab*
|
|
|
|
* Get your ghc MR to pass CI and get merged.
|
|
|
|
* Merge the ghc-head MR once the ghc MR has been merged. |
|
|
\ No newline at end of file |
