[Libwebsockets] Plan for 1.6
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:
>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
>> 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
>> zero. (It's not the same as zero bugs unfortunately, but it
>> The goal of the api rationalization was to get rid of the confusing
>> libwebsocket_ / libwebsockets_ api and struct prefixes and only use
>> 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
>> rebuild your app without changing anything (ie, keep the old api
>> 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
>> 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 ^^
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets