Hi, (replying to many of us in one shot :)
IMHO, the basic issue of the current versioning scheme is that, it requires at least some prior EB knowledge to extract useful information out of it. For experts that is not a big deal, but it confuses newcomers notably. It has served us well for 2 years, now some fresh ideas may be in need. My own wish is, that new users would be able to automatically extract information about a toolchain version, without prior knowledge about EB (and our discussions ;-) And my implied wish is that the experience can still be shared across many HPC sites! On Jun 3, 2014, at 11:18 PM, Kenneth Hoste wrote: > How could you possible 'encode' 5-6 different software versions into a single > (sensible) version number without losing information? I think we can all quickly agree that we can't: this is the same problem class as reducing a vector of numbers to one and still be able to reverse the function... almost a talk about hashing here. > One thing we will be doing across the different VSC (short for Flemish > Supercomputer Centre) sites in the Flanders region of Belgium is to use a > scheme like "intel/2014a", "intel/2014b" for (ictce) toolchains. This may prove to be actually a quite attractive scheme for the end-users, because it conveys information about when a toolchain was possibly "reviewed". As long as users don't make assumptions about versions being latest and greatest, this may work nicely with HPC user communities, with reasonable expectations. IMHO, "a" or "b" suffixes should rather be enumerators within 12 months (ie. permit up to 26 same-class toolchain releases a..z, within a year). Intel/ictce is a good example why a few releases per year are a must-have. goolf permutations also demo that this series is not always monotonic progress. (the .5 or .10 common suffix tried to deal with the latter... any better way?) On Jun 3, 2014, at 10:58 PM, Riccardo Murri wrote: > How about using a "year.month" scheme, e.g., goolf-14.06 would be the > GCC+OpenMPI+... that are current during June 2014? Yes, technically this is the same like the above, except for the naming details; RM's proposition is more Ubuntu-alike, yet functionally is pretty comparable. I think we should not be religious about the naming scheme, just find something that keeps most people following this (and users thereafter) happy. On Jun 3, 2014, at 9:13 PM, Jack Perdue wrote: > jack (learning EB in order to facilitate software > deployment on TAMU's new clusters) Talking about TAMU, here's a moment to ask about some other tricky bisiness, ref.: https://github.com/hpcugent/easybuild/wiki/Wishlist#modules-namespace-from-various-hpc-sites (fyi. this was an August 2012 wishlist - many things implemented already - congrats ;-) Jack, do you have as requirement the nested module namespace "netcdf/4.1.1/pgi/10.3/64" or, you plan to get away with it, by switching to Lmod-type hierarchical schemes instead? Basically, I wonder if you plan to develop custom-naming-schemes for module namespace, which is going to be an interesting experiment, one way or another, in your case. The challenging piece is, where "64bits" and such name variations end up living. thanks all for going through this, Fotis -- echo "sysadmin know better bash than english" | sed s/min/mins/ \ | sed 's/better bash/bash better/' # Yelling in a CERN forum
