[Libwebsockets] Plan for 1.6

Andrejs Hanins andrejs.hanins at ubnt.com
Mon Dec 7 08:48:23 CET 2015


On 12/07/2015 01:13 AM, Andy Green wrote:
> On December 7, 2015 6:10:35 AM GMT+08:00, Roger Light <roger at atchoo.org> wrote:
>> Hi Andy,
>>From what I can see you've covered the bases pretty well. The testing
>> I've done so far is all going fine.
>> Keeping the same soversion doesn't feel right, but I'm not sure what
>> the best thing to do is.
>> If LWS_WITH_OLD_API_WRAPPERS=off, then the ABI no longer matches and
>> so soversion should be bumped.
>> If LWS_WITH_OLD_API_WRAPPERS=on, then the ABI still matches and there
>> is no need for the soversion to be bumped.
>> That kind of implies that the soversion should be set based on whether
>> LWS_WITH_OLD_API_WRAPPERS is set or not, which doesn't feel exactly
>> right.
>> Could I suggest setting LWS_WITH_OLD_API_WRAPPERS=on by default, but
>> adding a #warning to the wrapper block to say that the old API is
>> deprecated and will be removed in 1.7 (or whatever).
>> If you keep LWS_WITH_OLD_API_WRAPPERS=off by default, I think the
>> soversion should be bumped.
> Yeah you are right we need to do something more... when I think about it from the perspective of the new api user, rather than it being about compatibility, he needs to assert that he wants to bind to a library version with the new apis.  So he needs an soname bump for that, otherwise he thinks he will be content with a library from months ago with no new api exports.
> The situation is not we bump it because we broke binary compatibility (with LWS_WITH_OLD_API_WRAPPERS on) but because we added some apis.

Any change to lws_callback_reasons (except appending to the end) breaks ABI, because enum values get shifted.
There were no SOVERSION bump since February despite the fact  LWS_CALLBACK_RECEIVE_PONG enum value was added
in October. I personally hit this bug when older LWS lib didn't work with client code compiled using
newer headers. So this is yet another reason to bump the SOVERSION and make sure it bumped every time
when some public enum is shifted by inserting a value in between.

> We could bump the soname and create a symlink with the old soname when LWS_WITH_OLD_API_WRAPPERS=on, like libwebsockets.so.5 -> libwebsockets.so.6... how does that sound?
> If it has problems we're just left with bumping the soname and explaining it's completely backwards-compatible when built with LWS_WITH_OLD_API_WRAPPERS.
> -Andy
>> Cheers,
>> Roger
>> On Sun, Dec 6, 2015 at 3:22 AM, Andy Green <andy at warmcat.com> wrote:
>>> Hi -
>>> Just a heads-up I'm planning to release 1.6 shortly.
>>> Although it's a short time since 1.5, we have a lot of new things.
>>>  - api rationalization (I explain in a moment)
>>>  - mingw and clang compatibility working
>>>  - mbed3 support usable (+/- the remaining mbed3 "500ms bug" they are
>>> working on fixing - https://github.com/ARMmbed/sockets/issues/38 )
>>>  - several fixed mainly on windows stuff
>>>  - big refactor on the test apps including an official pthreads
>> example
>>>  - cleaned out almost all windows build warnings (couple of
>> deprecated api
>>> warnings is all that is left)
>>>  - zero defects on coverity (3 small ones fixed)... they have an
>> interesting
>>> graph "average OSS defect density" is supposedly 0.35 per 100KLOC,
>> our
>>> density started at 0.05 a year ago when Joakim set up coverity and
>> now is
>>> zero.  (It's not the same as zero bugs unfortunately, but it
>> hopefully means
>>> something).
>>> The goal of the api rationalization was to get rid of the confusing
>>> libwebsocket_ / libwebsockets_ api and struct prefixes and only use
>> lws for
>>> everything.
>>> If you want to align your code with that, you can do it with
>>>  - /libwebsocket_/lws_/
>>>  - /libwebsockets_/lws_/
>>>  - /struct\ libwebsocket/struct\ lws/
>>> If you don't want to, or can't, update your user code, there are two
>> layers
>>> of backwards compatibility.... #defines in libwebsockets.h mean you
>> can just
>>> rebuild your app without changing anything (ie, keep the old api
>> names) and
>>> you're good to go.
>>> If you are building the library for distro type usage, and / or you
>> can't
>>> rebuild your app, you can enable a new cmake define
>>> This causes the library to build wrapper functions with the old
>> names, while
>>> also supporting the new names so you are compatible with both. For
>> that
>>> reason there's no soname bump involved.
>>> Any testing of HEAD would be helpful ^^
>>> -Andy
>>> _______________________________________________
>>> Libwebsockets mailing list
>>> Libwebsockets at ml.libwebsockets.org
>>> http://ml.libwebsockets.org/mailman/listinfo/libwebsockets
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> http://ml.libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list