In GitLab by @maerwald on Apr 26, 2022, 09:40

mentioned in issue ghc/ghc#21423

Some outline how this could work:

1. like with hackage/cabal we install the latest revision by default (e.g. ghcup install ghc 9.4.4 may install 9.4.4-r3)
2. revision as part of a version starts with -r0 (if none is given, -r0 is implied) and increases linearly (note there's a difference between 9.4.4 internally and 9.4.4 as requested by the user)
3. ghcup list/ghcup tui doesn't show the revision, unless it's not the latest (and then also prints a warning on startup, suggesting to update)
4. the user should also be able to install a specific revision via ghcup install ghc 9.4.4-r2 (this will be challenging to make work with the current parser, which is overly lax)
5. you can only install one revision of a given version
   • ghcup install ghc 9.4.4-r2 implies that e.g. 9.4.4-r1 is uninstalled as part of the installation
6. the ghc binaries will not be qualified by the revision, e.g. ghc 9.4.4-r2 will produce ~/.ghcup/bin/ghc-9.4.4
7. the internal ghc directory will be qualified by the revision, e.g. ~/.ghcup/ghc/9.4.4-r2

Open questions:

• how to use revisions in the ghcup metadata (we currently abused the fact that versions are keys, so we don't traverse the whole metadata to pick download info)

@mpickering @gbaz

PR: #803

One more reason to implement this: #1047