Louis Gesbert wrote: > For this specific bug,running "make tests" would have been enough > (I just tested on my VM). For being defensive and having ./configure > refuse newer version of dependencies, the m4 macros don't seem to > provide version filtering (only API testing. Here the API was > compatible, anyway that would have failed at build-time). Does > ocamlfind even provide an easy way to get the version of a package?
Version filtering isn't what I meant, though - I meant semantic filtering, i.e. a relevant test case which fails for this "broken" version but works in the older versions (or corrected newer versions). IMO, version filtering is something packagers do with package meta-data; developers should use version filtering only because of API changes which isn't applicable here. > But my feeling is that what happened really shouldn't happen -- I > mean, a small, but API compatible change, that would cause the older > version to break _but not the newer version, just by chance_, so > that it could get unnoticed ? What are the odds of this happening > _again_ ? ;) 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? David _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
