Changes between Version 8 and Version 9 of Commentary/Packages/PackageCompatibilityProposal

Oct 31, 2007 10:17:20 AM (10 years ago)



  • Commentary/Packages/PackageCompatibilityProposal

    v8 v9  
    5959This approach therefore doesn't scale to API changes that include types and classes, but it can cope with changes to functions only.
    61 == 4.2 Split base from underneath ==
     61== 4.2 Rename base, and provide a compatibility wrapper ==
    63 This requires the re-exporting functionality described above.  When splitting base, we would create several new packages and additionally a backwards-compatibility wrapper called `base` that re-exports all of them.
     63This requires the re-exporting functionality described above.  When splitting base, we would rename the base package, creating several new packages.  e.g. `base-3.0` would be replaced by `newbase-1.0`, `concurrent-1.0`, `generics-1.0`, etc.  Additionally, we would provide a wrapper called `base-4.0` that re-exports all of the new packages.
    7575 * Each time we split base we have to invent a new name for it, and we accumulate a new compatibility wrapper
    7676   for the old one.
     78== 4.3 Don't rename base ==
     80This is a slight variation on 4.2, in which instead of renaming `base` to `newbase`, we simply provide two versions of `base` after the split.  Take the example of splitting `base-3.0` into `base + concurrent + generics` again:
     82  * `base-4.0` is the remaining contents of `base-3.0` after the split
     83  * `base-3.1` is a compatibility wrapper, re-exporting `base-4.0 + concurrent-1.0 + generics-1.0`.
     85The idea is that all existing packages that worked with `base-3.0` will have
     87  build-depends: base-3.0
     89or similar.  To make these work after the split, all that is needed is to modify the upper bound:
     91  build-depends: base >= 3.0 && < 3.1
     93which is better than requiring a conditional dependency, as was the case with the `base-3.0` split.  In due course, these packages can be updated to use the new `base-4.0`.
     95Advantages: the same as 4.2, plus there's no need to rename `base` for each split.  Disadvantages: multiple versions of `base` could get confusing.  The upgrade path is still not completely smooth (existing packages all need to be modified manually).
    7897== 5. Do some kind of provides/requires interface in Cabal ==