#16200: Mechanical checking of submodule versions for releases -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description:
In the past there have been a few cases where we have put out GHC releases which have shipped with submodule versions which do not correspond with a released package version (e.g. #16199).
This should never happen. In principle the output of `git submodule` should be checked before a release is cut to ensure that all submodules point to tags. However, in practice this has proved to be insufficient due to two sources of false-positives:
1. our old mirroring infrastructure often failed to pick up tags 2. often we get away with a mere Hackage revision, which typically aren't tagged
Thankfully (1) should no longer be a problem with the move to GitLab. Moreover, now since we finally have reliable CI we can automate release creation. However, it's not entirely clear how to reliably verify the consistency of submodules in light of problem (2).
Unfortunately, it's quite tricky to avoid due to the existence of
New description: In the past there have been a few cases where we have put out GHC releases which have shipped with submodule versions which do not correspond with a released package version (e.g. #16199). This should never happen. In principle the output of `git submodule` should be checked before a release is cut to ensure that all submodules point to tags. However, in practice this has proved to be insufficient due to two sources of false-positives: 1. our old mirroring infrastructure often failed to pick up tags 2. often we get away with a mere Hackage revision, which typically aren't tagged Thankfully (1) should no longer be a problem with the move to GitLab. Moreover, now since we finally have reliable CI we can automate release creation. However, it's not entirely clear how to reliably verify the consistency of submodules in light of problem (2). -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16200#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler