A plan for enabling `index-state`

For a long time usability of head.hackage has suffered from the inability to freeze the state of the overlay in a particular project. A while back I met with with Andrea Bedini to discuss his work on foliage, a very nice tool for building Hackage repositories from a nice declarative input. This would serve as a very nice basis for head.hackage and happily, supporting both incremental builds and, crucially, index-state. We should move head.hackage's CI infrastructure towards foliage.

However, this will require that we slightly rethink how package versioning is handled. Currently patched packages retain their upstream package versions for simplicity. However, this will need to change in order to benefit from index-state since source tarballs are considered to be immutable in the Hackage index. At the same time, we will should avoid shadowing upstream package versions to avoid confusion. For this reason, I suggest that we version patched packages by bumping the fifth (sub-patch-level) component or, if the upstream version already has more than four components, the n+1th component. Concretely:

bumpVersionBy
    :: Int     -- ^ patch revision
    -> Version -- ^ upstream package version
    -> Version -- ^ patched package version
bumpVersionBy n ver =
    makeVersion ver'
  where
    n_comps = length (versionBranch ver)
    bump_comp = max 5 (n_comps + 1)
    bump = replicate (bump_comp-1) 0 ++ [n]
    ver' = zipWith (+) (versionBranch ver ++ repeat 0) bump

So we end up with,

bumpVersionBy 4 (makeVersion [1,0])         ===    Version {versionBranch = [1,0,0,0,4], versionTags = []}
bumpVersionBy 4 (makeVersion [1,0,0])       ===    Version {versionBranch = [1,0,0,0,4], versionTags = []}
bumpVersionBy 4 (makeVersion [1,0,0,0])     ===    Version {versionBranch = [1,0,0,0,4], versionTags = []}
bumpVersionBy 4 (makeVersion [1,0,0,0,0])   ===    Version {versionBranch = [1,0,0,0,0,4], versionTags = []}

Patch versions can be deduced from the commit history of the head.hackage repository. Specifically, I propose the following plan:

• For each patch $patch in patches/:
  • For each git revision $commit of the patch (i.e. for each commit shown by git log $patch):
    • Extract the source tarball
    • Apply the patch from $commit
    • Modify the cabal's version number; see "versioning" below
    • Run cabal sdist
    • Place the resulting source distribution in the foliage tree