blob: 8efb8f3791d258ba6dc796ca2ad222a1f9605b14 (
plain)
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
|
Multiple versions or not?
=========================
[ old notes. multi-versioning support was removed for the reasons below ]
Pros:
1. Mistakes or limitations in function definitions can be fixed without ugly
"_v2" or "_ex" functions
2. API level bugs can be fixed.
3. Behavioral changes can be done.
Cons:
- Limitation: Types cannot be changed, due to the "diamon dependency chain" problem.
- Public constants and inlined functions might not be possible to change in
practice (for the same reasons as for types)
- Complicates implementation.
- Source code examples could fail to work or do the wrong thing.
- Documentation needs to cover both new and old versions.
Alternative solution with module v2 renames
-------------------------------------------
- Enforce strict add-only versioning (no deletions or changes)
- Allow symbol deprecations (= warning) and symbol hiding (= error)
in incremental versions.
- Cleanups in major versions can be done as new modules
(e.g. module 1.9 vs module2 2.0)
With the steps above, mistakes/limitations and API level bugs can be fixed.
|
