[Libwebsockets] Plan for 1.6

Andy Green andy at warmcat.com
Tue Dec 8 04:13:40 CET 2015

On December 7, 2015 4:12:58 PM GMT+08:00, Andy Green <andy at warmcat.com> wrote:
>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
>>>> I've done so far is all going fine.
>>>> Keeping the same soversion doesn't feel right, but I'm not sure
>>>> the best thing to do is.
>>>> If LWS_WITH_OLD_API_WRAPPERS=off, then the ABI no longer matches
>>>> 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,
>>>> 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
>>it from the perspective of the new api user, rather than it being
>>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
>>(with LWS_WITH_OLD_API_WRAPPERS on) but because we added some apis.
>>Any change to lws_callback_reasons (except appending to the end)
>>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
>It was contributed and I didn't spot it.

I added this


...which converts all enums we control publicly to be set to explicit numbers (so it's painful / noticeable to ripple any unwanted number change along), and adds comments on the affected enums to only add things at the indicated place on each.

>Oh well I guess it solves what to do.

I also bumped the soname.

I'll wait a bit and if no new crises issue 1.6 this week.


>>> 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>
>>>>> 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
>>>>> libwebsocket_ / libwebsockets_ api and struct prefixes and only
>>>> 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
>>>> 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
>>>> 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
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org

More information about the Libwebsockets mailing list