libversion update question

historical

On Fri, Oct 20, 2017 at 01:23:27PM +0200, Max wrote:
> The rules are as follows:
>

c:r:a

> 1. If the library source code has changed at all since the last update, r++;
> 2. If any interfaces have been added, removed, or changed since the last update, c++,
> r=0;
> 3. If any interfaces have been added since the last public release, a++;
> 4. If any interfaces have been removed or changed since the last public release, a=0.
> 
> What's not clear to me is how those rules should be used. Do we apply them sequentially?

Yes, apply all of them in sequence.

> For example, I've added function lol_what() to public API of my library with previous
> LIBVERSION=3:2:1 and would like to compute new LIBVERSION properly.
> 
> According to rule #1 I've got to update revision: 3:3:1
> 
> According to rule #2 I've got to update current and reset revision: 4:0:1
> 
> The rules are conflicting so let's assume latest rule wins and apply further rules:

Not conflict, they build up on each other.

> According to rule #3 I've got to increase age: 4:0:2

Correct, and #4 does not apply.

> Now LIBVERSION=4:0:2 is released, I've removed lol_what() and added foobar()
> functions. Let's bump the LIBVERSION:
> 
> #1: 4:1:2
> 
> #2: 5:0:2
> 
> #3: 5:0:3
> 
> #4: 5:0:0
> 
> Am I interpreting this right?

Yes.

> We only increase revision if no interfaces have been
> added, removed, or changed since the last update? This means that "current" and
> "revision" increments are mutually exclusive.

Indeed, can be put this way. 'revision' is increased to indicate that some
internal behavior has changed, like bug fixes or optimizations, log output,
stuff like that. As soon as any API/ABI interface has changed, we need to
update 'current'. So it's like c:r make up a sort of semantic versioning, kind
of like 'major:patch'.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20171021/3002a5f4/attachment.bin>