This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn 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>