... | @@ -164,7 +164,7 @@ In any case, closing a ticket that was reopened can easily be considered as rude |
... | @@ -164,7 +164,7 @@ In any case, closing a ticket that was reopened can easily be considered as rude |
|
|
|
|
|
# Bump lib versions for development or release artifacts
|
|
# Bump lib versions for development or release artifacts
|
|
|
|
|
|
The safest way to bump lib version for newer development or release artifacts is:
|
|
The safest way to bump lib version for newer development or stable release artifacts is:
|
|
- if the library has not changed at all, leave version info untouched
|
|
- if the library has not changed at all, leave version info untouched
|
|
- if any change has been made to the library source code, bump 'current' and set 'revision' and 'age' to 0
|
|
- if any change has been made to the library source code, bump 'current' and set 'revision' and 'age' to 0
|
|
|
|
|
... | @@ -172,7 +172,7 @@ This will guarantee that the new library needs to be recompiled every time with |
... | @@ -172,7 +172,7 @@ This will guarantee that the new library needs to be recompiled every time with |
|
|
|
|
|
This can also be automate the process by the release procedure.
|
|
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.
|
|
Because of the current parallel model of using development and stable release versions, development libraries versions must never overlap with stable 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:
|
|
example:
|
|
```
|
|
```
|
... | @@ -223,9 +223,9 @@ lib3 version 35.0.0 (add 10 + 1 because the library code has diverged from relea |
... | @@ -223,9 +223,9 @@ lib3 version 35.0.0 (add 10 + 1 because the library code has diverged from relea |
|
lib4 version 8.0.0 (unchanged)
|
|
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 avoid version conflicts only between versions (development or release) sharing the same Major version.
|
|
This means that the current versioning scheme support unlimited number of development versions, but up to 10 stable release versions sharing the same Major version. This also means that this version scheme will avoid version conflicts only between versions (development or stable release) sharing the same Major version.
|
|
|
|
|
|
Also, the value for KEA_HOOKS_VERSION in `src/lib/hooks/hooks.h` must be incremented for every development or stable version. Note that development versions have a different (higher) values:
|
|
Also, the value for KEA_HOOKS_VERSION in `src/lib/hooks/hooks.h` must be incremented for every development or stable release version. Note that development versions have a different (higher) values:
|
|
```
|
|
```
|
|
kea-1.8.0
|
|
kea-1.8.0
|
|
|
|
|
... | @@ -242,4 +242,6 @@ const int KEA_HOOKS_VERSION = 10900; |
... | @@ -242,4 +242,6 @@ const int KEA_HOOKS_VERSION = 10900; |
|
kea-1.9.1
|
|
kea-1.9.1
|
|
|
|
|
|
const int KEA_HOOKS_VERSION = 10901;
|
|
const int KEA_HOOKS_VERSION = 10901;
|
|
``` |
|
```
|
|
\ No newline at end of file |
|
|
|
|
|
This means that up to 99 development versions will be supported before releasing a stable version. |
|
|
|
\ No newline at end of file |