On 24/08/16 19:03, Maxime Boissonneault wrote:
On 16-08-24 11:48, Vanzo, Davide wrote:
Toolchain versioning is bound to always be confusing, whatever the
choices are. A micro-version number won't solve the question... which
element of the toolchain was downgraded (or upgraded) ? My claim is
that date numbering makes more sense than incremental version
numbering... not that it makes actual sense. Lesser of two evils.
I agree that the current toolchain version numbering is quite confusing.
One question about date numbering: what if somebody wants to
downgrade one of the toolchain elements? Maybe a micro version number
would still be useful for this task.
That, in fact, is precisely why I'm against exposing toolchains to
users. Toolchains are a necessary burden because of the way EasyBuild
is made, but are very awkward for users (not even mentioning their
To chime in on this discussion:
The original versioning scheme for toolchains was very ad-hoc indeed;
the reasoning used in this thread (major version bump of one or more
components, leave room to downgrade the toolchain version if needed,
etc.) align well with the rules of thumb that we were using to version
However, the point that this versioning is meaningless is valid, and
explains why we've been favoring date-based versioning instead.
The idea there is that the release date of the most recently released
component determine the toolchain version, usually <year>.<month>; at
least that has some intuition to it.
With respect to the issue of downgrading: how about handling that
problem when it actually occurs?
There are various possible options there, like adding another component
to the version (<year>.<month>.<variant_id>), or using a versionsuffix
to make it very clear how it diverges from the 'standard' composition.