[asdf-devel] has ":depends-on ((:version ...))" semantics changed?

[Pascal Costanza]

The 0.xy versions of Closer to MOP were not based on semantic versioning, but on an ad hoc versioning scheme. 1.0.0 did not change any API at all, so is definitely compatible with the last 0.xy versions. 1.0.0 is supposed to acknowledge the maturity of the library, that's it. 

The FAQ section at http://semver.org seems to suggest that exceptions to the rules are acceptable, and I believe that a change from ad hoc version numbers to semantic versioning is such an exception.

I'm open to suggestions for a better solution.

Pascal

Sent from my iPad

> On 18 Nov 2013, at 04:50, "Robert P. Goldman" <rpgoldman at sift.info> wrote:
> 
> Wait, what?
> 
> Are you saying now that version 1.0.0 of Closer-MOP will satisfy the
> requirement of 0.55, and that Anton should *not* be having this build
> failure.
> 
> Because I don't think it *is* a bug.
> 
> If someone releases version 2.0 of a software package, and I have a
> library that relies on version 1.x, I *want* to be warned that the API
> has moved under me.
> 
> For that matter, if a library has been unmaintained for three years (I'm
> talking about you, moptilities!) while its dependencies have moved under
> it, I would like to be warned that it's likely not to be working.
> 
> I'm willing to see some special-purpose kludge to break this for the
> ASDF upgrade case, because we have set things up so that ASDF upgrades
> should work whenever one version is greater than another.
> 
> Even for ASDF, code that relied on old versions of the ASDF API should
> not be fooled into thinking that it will be forward compatible.  That's
> why I insisted on bumping to ASDF 3 to reflect the fact that the API had
> changed.
> 
> MOPTILITIES *should* break under the current circumstances; that's not a
> bad thing.  Either someone should look and see if it's compatible with a
> new version of Closer-MOP and take the 2.4 seconds required to bump the
> :VERSION dependency, or if it's not worth anyone's time to do that,
> maybe it's not a library that people should be using, and it should get
> garbage-collected from the community.
> 
> Best,
> r
>