Cversion attribute in <condition> element does not allow to change major version

[ReinhardKeil]

The Cversion attribute in the <condition> element specifies a minimum version. The documentation is unspecific on behavior of major version changes. However with Semantic versioning the change of MAJOR version number implies an incompatible change. The CMSIS tools implement an algorithm that does not allow to cross MAJOR version (except when an explicit version range is specified with a maxVersion that has a higher major version).

The documentation needs clarification under:
https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/pdsc_conditions_pg.html#element_require

Questions:

• there is an inconsistency of the version evaluation in element <requirements> elements. A pack with a higher major version is accepted. Can you confirm?
• what is the best way to specify that a MAJOR version change is acceptable. Cversion=5.6.0:6 is accepted, but what is the actual behaviour.

[edriouk]

I can confirm that packs do not follow the MAJOR rule, they got accepted.
In the current implementation only an explicit range can be used to accept greater version.
for the given range Cversion=5.6.0:6 all components from 5.6.0 till 6.0.0 are accepted (6.0.1 gets rejected)

We can still modify most of the tools with:

• user option (command line, preference setting) to ignore MAJOR rule
• modify version range comparison to use open expressions like Cversion="5.6.0:" to explicitly ignore the MAJOR rule

[jkrech]

I think the bit we are missing with version range minVer:maxVer is to be able to specify whether the specified maxVer is included or excluded. Currently it is included:
minVer:maxVer means minVer >= VERSION <= maxVer
In order to specify a dependency with a version that spans across multiple major versions

<accept ... Cversion="5.6.0" />
<accept ... Cversion="6.0.0" />
<accept ... Cversion="7.0.0" />

since

<accept ... Cversion="5.6.0:7.999.999" />

is a speculative hack.

In the CMSIS-Toolbox project format we have defined:
@~6 to specify that any version having major version 6 would match
versus
@>=6.0.0-0 which would accept any version with major version >=6 (no upper limit).
The challenge I am seeing is that any change/moidification will break compatibility.

[edriouk]

Please note that range "1.0.0:2.0.0-" effectively covers all 1.xx.xxx version and excludes any 2.0.0 (even pre-release)
It effectively does the same job as "1.0.0:1.999.999" but looks nicer.

[jkrech]

@edriouk I had not thought about that !!!

Note: in order for the version to be schema compliant something needs to follow the -

1.0.0:2.0.0-0

[ReinhardKeil]

@edriouk is it today possible to use Cversion=5.6.0:7.0.0- in all our tools? Will this be handled as described by you? If so, we add it also to the documentation, as this topic is a documentation issue.

[jkrech]

Cversion:

Specifies a software component version

require Cversion: condition is true if version of component is equal or higher than requested but compatible. According to Semantic Versioning compatibility requires the major version to remain unchanged.

deny Cversion: condition is true if version of component is lower than requested.

Version ranges are specified with min_version:max_version. The condition is true if the version of the component is equal or higher than min_version and lower or equal than max_version. If min_version and max_version are equal the version must match exactly.

Only specifying the min_version Cversion="4.1.0" is identical to the version range Cversion="4.1.0:5.0.0-0"

[edriouk]

@ReinhardKeil , semantic versioning works consistently across our tools, including Cversion=5.6.0:7.0.0-
However, schema check will fail for such expression, Therefore Cversion=5.6.0:7.0.0-0 should be used