[Libwebsockets] Plan for 1.6

Andy Green andy at warmcat.com
Mon Dec 7 09:12:58 CET 2015

On December 7, 2015 3:48:23 PM GMT+08:00, Andrejs Hanins <andrejs.hanins at ubnt.com> wrote:
>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
>>> is no need for the soversion to be bumped.
>>> That kind of implies that the soversion should be set based on
>>> 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.

Ouch... actually that's not new to me I have been adding things at the end.

It was contributed and I didn't spot it.

Oh well I guess it solves what to do.


>> 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
>> -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
>>>> 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
>>> 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
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org

More information about the Libwebsockets mailing list