[Bordeaux-threads-devel] Deprecating recursive locks

[Anton Vodonosov]

18.04.2012, 01:48, "Anton Vodonosov" <avodonosov at yandex.ru>:

>  If the public API is changed in a not-backward-compatible way, I would
>  suggest to release new ASDF system (bordeaux-threads2), and
>  leave the old version available in quicklisp forever.
>
>  People who are ready to use new version, just add bordeaux-thread2
>  into their ASDF dependency. Others are able to use old version.
>
>  This is a good practice. And it costs nothing.
>
>  Some links on this subject:
>  http://lispcaveats.tumblr.com/post/13259176455/ffi-linking-against-shared-libraries
>  http://semver.org/

How to handle backward compatibility of bordeaux-threads if the API is changed
is up to the maintainer.

Still, I think the approach I suggest may be a good solution for lisp libraries
evolution, and I would like to present some arguments to support this approach.

18.04.2012, 08:15, "Attila Lendvai" <attila.lendvai at gmail.com>:

>  IMHO it's not a good practice and it does cost complexity/noise.
>
>  you lose the clarity around the digital representation(s) of the
>  identity of the library. there's only one b-t library, and the fact
>  that it has changed in a way that made it incompatible with something
>  else does not change its identity.

No, I only suggest to create separate ASDF system and package
for new version of the API. It is not uncommon for lisp project to
have several ASDF systems and packages. Should these packages
be delivered in the same tarball? They may, but non necessary.
(depending what is more convenient for the maintainers).

As for the library identity, it can remain the same. What is meant by
the library identity and how it is used? Project home page will remain the same,
for example, mailing list is the same. I.e. it still remains the same
project.

If we had two bordeaux-threads versions, one with recursive
locks, and one without, why not allow suers to name exactly what
API their programs need.

22.04.2012, 18:41, "Stelian Ionescu" <sionescu at cddr.org>:

>  On Wed, 2012-04-18 at 01:48 +0400, Anton Vodonosov wrote:
>>   Some links on this subject:
>>   http://lispcaveats.tumblr.com/post/13259176455/ffi-linking-against-shared-libraries
>  That post contains a good analysis of the problem, but then gives the
>  worst possible advice to solve it

Why?

At least, this statement is to strong - one can easily create 10 advices worse than
the post gives :)

If speak seriously, in my opinion referring major version, i.e. specific API, is a good advice.

>>   http://semver.org/
>  Point 5 says "Major version zero (0.y.z) is for initial development.
>  Anything may change at any time. The public API should not be considered
>  stable". So no problem there

I do not mean we have problem because we contradict some text. I mean that
if we have practical problem that N systems will stop to compile after the
b-t API changes, leaving the old "frozen" version of API available for these
libraries may be a good practical solution for this problem.

And the approach of distinguishing changes which modify public API
from ones which do not modify the public API is not new. Thus the links,
and more examples may be found.

IMHO this approach frees the library API to evolve easily, without requiring
efforts from the library maintainers, and at the same time not breaking any
other systems.

Best regards,
- Anton