Anyone interested in "package versioning"?

[Stelian Ionescu]

On Sun, 2016-05-22 at 14:33 +0300, Anton Vodonosov wrote:
> 
> 19.05.2016, 11:00, "Hans Hübner" <hans.huebner at gmail.com>:
> > 
> > The real issue though is data types defined by versioned libraries.
> >   Suppose that an instance of a data type defined in library A
> > version 1 is passed, through higher levels of the software, to
> > version 2 of that same library.  How would one ever expect that to
> > work?
> > 
> 
> Can that happen without us on the higher level knowingly passing
> object created by one API, to another, incompatible API, which
> doesn't accept such objects?
> 
> I was thinking about that too, but now it appears to me that if
> incompatible changes in API are marked as such (e.g. by giving the
> API new name), we always know that the second API is incompatible and
> can not accept this object.
> 
> Do you have examples? It would be interesting to explore this problem
> further.

I gave a few in a previous message here:

It's easy to come up with such a case, where a library:
*) switches from CL epoch timestamps(1900-based) to Unix epoch(1970)
*) switches from Unix namestrings to URIs
*) switches from relative CL pathnames with implicit base to absolute
pathnames

In each of these cases, the single versions pass their own internal
(unit) tests, but they do not integrate. If libraries change the
semantics of slots whose types are standard CL types, you can't even
detect this without extensive integration tests.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20160522/4787d911/attachment.sig>