> Again, in my opinion, "once bitten, twice shy". My own personal experience is > that if something like this has happened it is *very* likely it will happen > again (and that's in no way a negative comment on any developers concerned!) > > There are plenty of other instances in configure scripts where semantics are > tested rather than a version compatibility matrix (usually when probing the C > compiler) so I don't think it's too unusual a thing to want to do?
Yup, I was half-joking... In this case though I have really no idea of what precise aspects of the semantics we may want to check (to be honest, I didn't even dig enough to see what change caused that bug -- because by the time it was done Opam was already fixed ; it's most likely a change in the Debian module, and what I can tell is that we _were_ assuming a consistent cudf-version numbering scheme among slightly different package universes, which wasn't specified. Also, that could well have had that kind of consequences ; but I'm still speculating). My point was that if we stick to specified APIs, we _shouldn't_ run into that ; as for the semantics, really, I don't see better than running `make tests` for testing them, and shouldn't that sound obvious before shipping a package ?
_______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
