blob: 6e33a6b64c40a572cb4b4389761a78a86304a04d (
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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
It would be nice if versioning could be:
* safe from developer errors
(preferably 100% safe)
* preferably more or less fully automatic
* support backports
- even from a 3rd party, such as a distributor.
Versioning can be done at different "levels":
* Module (=library)
- Can lead to faster load times
* Symbol
- Makes backport handling easier.
- Functions can be added in any order.
Version info can be generated at different "places":
* By the library developers
- verified either by the compiler or by the package repo
* By the compiler
- and of course verified by the package repo
* At the package repo
- i.e. implicitly or explicitly on upload
- the upload CLI/API/UI could require approval of API additions,
and API bumps due to incompatible changes.
Versions "types":
* Dotted versions, with backport support
- e.g. 1.6.0, but also things backports like 1.4.9.2, or other
kinds of formats such as 2024.09.30-git-12345abcde
- it is easy to get these wrong, for example:
- bumping the wrong component
(e.g. from 1.1 to 1.2 instead of 2.0 or vice versa)
- bumping to a final version too early
- bumping to a "far-future" version accidentally
* Simple sequence numbers
- This does not support backports, so it's rather limited
* Hash-based versions
- Based on API contents.
- Can support any number of preceeding versions (= subsets)
and these can be added after-the-fact.
- Could have infintely many subsets, but to be pragmatic, only
actually used (uploaded or referenced) subsets should be
allocated.
- Handles backports flawlessly!
Maybe sort all functions by name... TODO
Development experience
----------------------
* It should be possible to change an interface while developing
|
