[Libwebsockets] Plan for 1.6

Andy Green andy at warmcat.com
Mon Dec 7 00:13:49 CET 2015

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

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.


>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
>>  - 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
>> graph "average OSS defect density" is supposedly 0.35 per 100KLOC,
>> 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
>> 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
>> 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
>> 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

More information about the Libwebsockets mailing list