blob: 6b89526c920d5db1ed25841071d40f1cb1bd1a54 (
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
|
SLUL misc versioning topics
===========================
1. How to let OS distributors create own versions, while still supporting the upstream version?
2. How to support different SLUL versions for implementation and interface?
1. OS distributor versioning
----------------------------
Without API changes, it is simple:
\slul 0.0.0
\name example
\type library
\version 1.2.3+distpatch1
(other versioning conventions such as 1.2.3-1 are also fine, as long as they
don't conflict with the upstream project)
With ABI changes, it gets trickier:
\slul 0.0.0
\name example
\type library
\version 1.2.3+distpatch1
\abi_def 1.0.0 xxx
\abi_def 1.1.0 xxx
\abi_def 1.1.0+distpatch1 xxx
\abi_def 1.1.1 xxx
\abi_def 1.1.1+distpatch1 xxx
...and so on...
The API change would require a new abi_def in each following API version
(although ones that are not released in the distribution do not strictly
need a "distpatch" API version)
2. Separate SLUL version for module implementation
--------------------------------------------------
\slul 0.1.0
\name example
\type library
...
\impl_slul 0.2.0
\source implfile1.slul
\source implfile2.slul
Building the module would require SLUL 0.2.0 in this example, but using the
module would only require SLUL version 0.1.0.
|
