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

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
>> -DLWS_WITH_OLD_API_WRAPPERS=1
>>
>> 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




More information about the Libwebsockets mailing list