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


Ignore:
Timestamp:
Oct 31, 2007 10:17:20 AM (6 years ago)
Author:
simonmar
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • 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. 
    6060 
    61 == 4.2 Split base from underneath == 
     61== 4.2 Rename base, and provide a compatibility wrapper == 
    6262 
    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. 
    6464 
    6565Advantages: 
     
    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. 
     77 
     78== 4.3 Don't rename base == 
     79 
     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: 
     81 
     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`. 
     84 
     85The idea is that all existing packages that worked with `base-3.0` will have 
     86{{{ 
     87  build-depends: base-3.0 
     88}}} 
     89or similar.  To make these work after the split, all that is needed is to modify the upper bound: 
     90{{{ 
     91  build-depends: base >= 3.0 && < 3.1 
     92}}} 
     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`. 
     94 
     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). 
    7796 
    7897== 5. Do some kind of provides/requires interface in Cabal ==