Hi all,

On 24/08/16 19:03, Maxime Boissonneault wrote:
On 16-08-24 11:48, Vanzo, Davide wrote:
Maxime,
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.


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.

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 obscure naming...)

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

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.


regards,

Kenneth

Reply via email to