[ET Trac] [Einstein Toolkit] #241: Thorns should be able to specify implementation versions, and other thorns should be able to depend on those

[Einstein Toolkit]

#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.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/241#comment:23>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit