18.04.2012, 01:48, "Anton Vodonosov" avodonosov@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-li... 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@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@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-li...
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.
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