One possible example of a principle is:
No unexpected breakage.
The impact of all breaking changes should be known to the upstream projects doing the breaking in advanced to vet the change. Downstream projects goes through should also be warned in advanced with a proper deprecation cycle.
Two examples of projects that implement it:
-
[Pre-HFTP] GHC.X.hackage: A tool for easing migrations to new GHC versions - #10 by Ericson2314 Helps ensure library continuously build with upcoming GHCs, so we aren’t blindsided or blocked on GHC 9.0 situations.
-
@sclv’s Deprecating _source_ of an imported module. · ghc-proposals/ghc-proposals · Discussion #489 · GitHub helps avoid the situation @andreasabel pointed out MTL release candidates in Deprecating _source_ of an imported module. · ghc-proposals/ghc-proposals · Discussion #489 · GitHub (second is a comment link). We lacked a way to do warnings on such things before without causing silly module classes.
Being able to witness in the HFTT repo that both initiatives work together can help weave together a larger initiative out of discrete HFTT proposals. It helps confirms a project like warnings on reexports as something worth accelerating with HF resourcing if we decide to do GHC.X.hackage, because the benefit of both projects together is better than that of each alone.