[asdf-devel] In defense of ASDF & Semantic versioning

[Anton Vodonosov]

19.11.2013, 23:41, "Robert P. Goldman" <rpgoldman at sift.info>:
> it's too radical
It's not radical, actually my proposal is very similar to yours

> It's like having a purely functional programming language 
Yes, I see this as an FP analogy too and expect that avoiding
mutations and destructive changes will simplify life
for developers.

> with no garbage-collection! 
Why without garbage-collection? We are not leaking any resources.

> We'd be left with heaps of unmaintained and unmaintainable
> versions of basic-lib floating around in the worse case.

The amount of library versions does not change in the approach
I propose. But versions with different APIs are have different names.

And we deal only with versions we use, and can forget about any
other versions.

> Also, the two different libraries won't live happily in the same lisp
> image, unless they change package

Wait, I do propose to change package

> at every release

at every API incompatible change (in other words, for every new API).

> This approach seems like it will be such a monumental pain for the
> library maintainers, 

What pain do you mean? It's a zero cost solution. It requires no
additional efforts from library maintainer, and even no special
support from ASDF and other tools.

> and anyone who wishes to upgrade his/her client program
> from basic-lib to basic-lib2

The client job remains the same: if he wants to migrate to
the new API he rewrites parts of his code using new functions.
Nothing above that.

Moreover, as client can have access to both APIs simultaneously,
he can sometimes migrate partially: leave his old tested code
as is (using basic-lib), but in the places where he needs
new functionality he calls basic-lib2.
So, client can benefit from new features without investing
efforts into rewriting and retesting code.

> I'd argue that having two versions of the same library *in the same
> image* is too demanding a target.

It's not a target. The target is to not break clients.
It's rather a tool to achieve this target, or a pleasant side-product
of a cheap decision to name different things differently.

Please think about this approach a little more.
IMHO this approach is convenient and I would recommend
it as the first thing to consider to anyone who is going
to change API of a public library.

Am I missing anything?

Best regards,
- Anton