Change in versioning scheme for libnl3, next release being 3.3.0

Thomas Haller thaller at redhat.com
Mon Feb 27 15:21:59 PST 2017


Hi all,


the version number of recent libnl3 releases had 3 components, where
the 3rd part was bumped, like 3.2.28, 3.2.29
( https://github.com/thom311/libnl/releases ).

For future releases I plan to bump the second number, so the next
release would be be 3.3.0 (instead 3.2.30), then 3.4.0, 3.5.0, etc.

Of course, 3.3.0 will not break API/ABI. I think libraries should try
very very hard not to break compatibility. An intentionally
incompatible libnl release would be named libnl4 anyway (which is
unlikely to happen).

There will still be 3 components "3.3.0" because it leaves space in the
numbering scheme for an upstream stable/minor releases like 3.3.1  (but
doing upstream minor releases is not planned and possibly not gonna
happen).


Comments?


best,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20170228/fe52d5df/attachment.sig>


More information about the libnl mailing list