... | ... | @@ -170,4 +170,59 @@ The safest way to bump lib version for newer development or release artifacts is |
|
|
|
|
|
This will guarantee that the new library needs to be recompiled every time with entire source tree, avoiding any bad linkage or dynamic symbol loading.
|
|
|
|
|
|
This can also be automate the process by the release procedure. |
|
|
\ No newline at end of file |
|
|
This can also be automate the process by the release procedure.
|
|
|
|
|
|
Because of the current parallel model of using development and release versions, development libraries versions must never overlap with release libraries versions (for the same Major version). To implement this, after each release, all development versions will be incremented with 10 + 1, but only the first time the library is modified and diverges from the release code.
|
|
|
|
|
|
example:
|
|
|
```
|
|
|
kea-1.8.0
|
|
|
|
|
|
lib1 version 10.0.0
|
|
|
lib2 version 4.0.0
|
|
|
lib3 version 23.0.0
|
|
|
lib4 version 7.0.0
|
|
|
|
|
|
kea-1.9.0
|
|
|
|
|
|
lib1 version 10.0.0 (unchanged)
|
|
|
lib2 version 15.0.0 (add 10 + 1 because the library code has diverged from release)
|
|
|
lib3 version 23.0.0 (unchanged)
|
|
|
lib4 version 18.0.0 (add 10 + 1 because the library code has diverged from release)
|
|
|
|
|
|
kea-1.9.1
|
|
|
|
|
|
lib1 version 10.0.0 (unchanged)
|
|
|
lib2 version 16.0.0 (add 1 because the library code has changed yet again)
|
|
|
lib3 version 34.0.0 (add 10 + 1 because the library code has diverged from release)
|
|
|
lib4 version 18.0.0
|
|
|
|
|
|
kea-1.8.1
|
|
|
lib1 version 10.0.0 (unchanged)
|
|
|
lib2 version 5.0.0 (add 1 because the code has changed) - merged changes from development into stable release
|
|
|
lib3 version 24.0.0 (add 1 because the code has changed) - merged changes from development into stable release
|
|
|
lib4 version 7.0.0 (unchanged) - nothing merged from development into stable release
|
|
|
```
|
|
|
|
|
|
After a new major release, the process starts again with development versions matching release versions.
|
|
|
|
|
|
example:
|
|
|
```
|
|
|
kea-2.0.0
|
|
|
|
|
|
lib1 version 10.0.0
|
|
|
lib2 version 5.0.0
|
|
|
lib3 version 24.0.0
|
|
|
lib4 version 8.0.0
|
|
|
|
|
|
kea-2.1.0
|
|
|
|
|
|
lib1 version 10.0.0 (unchanged)
|
|
|
lib2 version 16.0.0 (add 10 + 1 because the library code has diverged from release)
|
|
|
lib3 version 35.0.0 (add 10 + 1 because the library code has diverged from release)
|
|
|
lib4 version 8.0.0 (unchanged)
|
|
|
```
|
|
|
|
|
|
This means that the current versioning scheme support unlimited number of development versions, but up to 10 release versions sharing the same Major version. This also means that this version scheme will only avoid version conflicts only between development version sharing the same Major version.
|
|
|
|
|
|
|