Release schedule and stable releases

[Cong Wang]

On Tue, Mar 17, 2015 at 10:51 AM, Thomas Haller <thaller at redhat.com> wrote:
> 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.
>

_Essentially_ we will add a capability for every commit, unless
you have no plan to allow 32k commits for libnl.

I know you will argue we will only add a few in practice, but different
users may need different commits, this is why I said it doesn't
scale.

>
> 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.

This is not a problem since Mesos uses autoconf, I never say
your way doesn't work, it simply doesn't scale.