Release schedule and stable releases

[Thomas Haller]

On Tue, 2015-03-17 at 10:13 -0700, Cong Wang wrote:
> On Tue, Mar 17, 2015 at 3:26 AM, Thomas Haller <thaller at redha

> > But IMO there is another good solution:
> >
> >
> > nl_has_capability() can help to decide whether you need to workaround a
> > bug:
> >  https://github.com/thom311/libnl/blob/50a76998ac36ace3716d3c979b352fac73cfc80a/lib/utils.c#L1115
> >  http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/platform/nm-linux-platform.c?id=641a57994c83ed3622002b2d40fc1f9b030057bf#n4029
> >
> > A capability tells you if libnl has a certain fix. On a per-fix basis!
> > These capability numbers are upstream and stable. "1" means everywhere
> > NL_CAPABILITY_ROUTE_BUILD_MSG_SET_SCOPE.
> >
> 
> We already use nl_has_capability() in Mesos to test features we need,
> but this way doesn't scale for bug fixes, it is limited by its int parameter.

I don't see the problem here. Every new capability adds only 1 bit to
libnl at runtime and one enum-value+#define in the sources.

int is at least 16 bit, so we can have plenty of numbers (32k).

Why doesn't it scale? For every relevant patch, we can add a capability.
I will merge every capability number that is helpful to a user.


Why can Mesos upstream then not have a compile time check
  #ifndef NL_CAPABILITY_HAS_FIX_fffc7ece
  #error update libnl
  #endif
?

That, together we doing major releases more frequently.


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/20150317/e9df0057/attachment.sig>