-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
53 lines (46 loc) · 3.5 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
Reverses the concept of versioning. Something that depends on a library provides a target version, and libraries provide compatability info.
The rationale behind this is that it's unfair on the consumer of a library to force them to keep track of
something they have no control over, that is, changes to libraries they consume. Furthermore the consumer
of the library may not be aware of all the changes that occur in a library going from one version to another,
whereas presumably the author of the library (or the one doing the changes) is aware when they make a change
that breaks compatability (in haskell this would typically be a change to a type signature of a function).
The initial effort involved in annotating a library should be rather minimal (probably could make a utility
to generate default annotations much like the -auto-all option for profiling annotations) and going from
version to version should just be a matter of updating the annotated functions and types as you make
changes to them. A compatability breaking change would be one where the type signature of a function changes,
or the input or output of the function changes in a way that's inconsistent with the documented behavior.
Bug fixes in general should not be compatability breaking changes, baring a major re-write of a function.
At a minimum the Partial compatability of a module is the lowest version number any of its functions or types
are compatable with and the Full compatability is the highest version number all of its functions and types
are compatable with.
At the library level compatability info is provided via annotations at the module, type, and function levels.
Any type of function that is un-annotated implicitly shares the compatability info of the containing module.
A module need not have the same compatability as all of it's functions, but it should for most of them.
Should support the concept of a partially compatible instance.
A program that uses a module specifies a target version. All functions from that module used by the program
are checked for compatability with the specified target version.
Target info would be provided by both annotating a import statement, and most likely in something like a cabal package.
Example:
Module A v2.4.2: Partial > 2.1.0 && Full > 2.4.0
Function1: Full > 2.1.0
Function2: Full > 2.2.0
Function3: Full > 2.4.0
Function4: Full > 2.4.2 <-- In this example this is a new function, hence the module as a whole is still compatible with 2.4.0
Compatible:
Program v1.0.0:
Modula A: Targets 2.2.0 <- Partially Compatible, check proceeds to per function targets
Function1: Targets 2.2.0
Function2: Targets 2.2.0
Not Compatible:
Program v1.2.0:
Module A: Targets 2.2.0 <- Partially Compatible, check proceeds to per function targets
Function1: Targets 2.2.0
Function2: Targets 2.2.0
Function3: Targets 2.2.0 <-- No compatible instance available
Issues:
Makes it hard to upgrade libraries to a definitely compatible version... you could always fetch the latest
version that's fully compatible, but there's a possibility a later partially compatible version could be used as
well. Without running a per-function version check you can't tell though.
Possible solutions:
Export the complete compatability data to an external file, E.G. ModuleA.compat, and likewise export target info.
This allows a check of the compat files for all versions of a module to be executed given a target version.