#241: Thorns should be able to specify implementation versions, and other thorns should be able to depend on those --------------------------+------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: review Priority: minor | Milestone: ET_2016_05 Component: Cactus | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
I commented inline in the pull request. Summary of comments:
I would start with "All capabilities have an optional version attached". I still think that allowing the version string to start with anything is better. The reason being that (to me) the "natural" way to give a version to an ExternalLibrary is to use version_of_upstream_code-N where N is the version of our own scripts in the ExternalLibrary (this is more or less how Debian seems to do this). So if OpenMPI names there versions {{{v17.5-experimental:2015}}} then I'd name the version of HDF5 that includes that tarball {{{v17.5-experimental:2015-1}}}.
I did not catch this in the perl code, but I think we should allow spaces in the same location that C would ie surrounding operators and parenthesis and not require that there is no space between the comparison operator and the version number. Is there any benefit to the restriction?
- \item[$=$] Requesting capability exactly equal to given version
This should be "==", should it?
non-digit characters is determined. The two parts are compared
lexically, and "the two parts" was confusing me when I first read it. You are really referring to the second parts of each version string, but on first reading it "the two parts" sounded like the first and second part (ie the numerical and the non-numerical) part of one of the version strings.
I would try and make sure that "numerical" makes it clear that "integer" is meant and not also floating point ie that "1.0.0" is 5 parts: 3 numerical and 2 non-numerical.
I would use (for reasons outlined above) {{{ (>=2.43.2dev-1) }}} to give an example of a version number that we'd like to see used.