CIM Issues » WG13 Issues

Chavdar, a couple of questions. For the proposed solution options you have described i.e. xx.yy.zz or http://iec.ch/TC57/CIM/{package name}/xx.yy. I would like to simply formalize what types of UML changes fall into each component of the semantic version. I'd like to additionally document this in the CIM modeling guidelines document.

xx -> As part of semantic versioning this would translate to breaking changes within the package such as:
- A class is removed
- A class is renamed
- An attribute is removed from an existing class
- An attribute is renamed within an existing class
- An association is removed
- An association role end is renamed

yy -> As part of semantic versioning would translate to non-breaking changes within the package such as:
- A new class is added
- A new attribute is added to an existing class
- A new association is added

zz -> As part of semantic versioning would translate to very minor non-breaking changes within the package such as:
- description of the package is updated/clarified
- description of an existing class is updated/clarified
- description of an existing attribute is updated/clarified

Additional questions/assumptions we should formalize:
- What if a package is added under an existing package (e.g. a new child package under the Base package)? Is our position that the semantic version of the Base package would or would not change to reflect this addition? Currently, I do not see a reason to change the version of the parent package (i.e. for Base in this example). Just want us all to be on the same page.
- Do we update the semantic version IF a UML diagram is updated or do we restrict to only changes to the UML proper? At first UML proper seemed reasonable but I vacillate.
- Currently for your URI-based option it seems to me we'd also want to include 'zz'. Thoughts?

Chavdar (et al.), please add/modify/clarify what I've proposed here.

Todd, very good
in the xx we can add
- description is modified to a higher degree potentially changing the meaning
- constraint is added - that maybe in yy

I guess if a package is added to Base this is yy increase of the version as this should bring features. It will also depend if this package will have to do something with classes under Base. In case the versioning of Base might not be super useful - just on global level. What will be really good if the versioning of the packages down the hierarchy

I think versioning of diagrams might not bring that much

on the URI. If we want to have more stable approach we can keep the URI without the zz and have the zz in another tag value. The zz should normally be editorial changes that would not need change in implementation. So if we use the URI to actually get the vocabulary for that package the http://iec.ch/TC57/CIM/Core/17.40 will always refer to the latest revision but the URI would only have xx.yy. In fact if we want to really publish this we can use the ucaiug domain instead of iec.ch. Basically an RDF export of that vocabulary can be published there

Chavdar, excellent! Thanks for your feedback as that what I was hoping for. Your additional suggestions make solid sense. Also you clarifications on the URI-base approach is helpful and we will be able to discuss better when Eric and I set up the meeting with the Becky and Henry. Anything else you end up thinking of please add to this thread. :)

From WG13 November 24, 2022 Meeting:

o Proposed using existing package properties (uri, version and package) for version.
o Proposed: start at 1.0 (major.minor version)
o Applied to the base CIM17v40 version that we used as baseline for CIM18 going forward.

Discussion on xx.yy.zz release format from the Issue 5111:

xx > As part of semantic versioning this would translate to breaking changes within the package such as:
A class is removed
- A class is renamed
- An attribute is removed from an existing class
- An attribute is renamed within an existing class
- An association is removed
- An association role end is renamed

yy > As part of semantic versioning would translate to non-breaking changes within the package such as:
A new class is added
- A new attribute is added to an existing class
- A new association is added
- description of the package is updated/clarified
- description of an existing class is updated/clarified
- description of an existing attribute is updated/clarified

zz -> As part of semantic versioning would translate to very minor non-breaking changes within the package such as:
-syntax generation
-spelling mistakes, editorial fixes etc

Additional questions/assumptions we should formalize:
- What if a package is added under an existing package (e.g. a new child package under the Base package)?
- The packages will follow the same rules as the classes. (above)

Is our position that the semantic version of the Base package would or would not change to reflect this addition? Currently, I do not see a reason to change the version of the parent package (i.e. for Base in this example). Just want us all to be on the same page.
- The packages will follow the same rules as the classes. (above)

- Do we update the semantic version IF a UML diagram is updated or do we restrict to only changes to the UML proper? At first UML proper seemed reasonable but I vacillate.

• The assumption is that the current version of the 301v7.1 is 1.0.
• In the 302 ed2 we should put in 1.0 for the package version.
• If we had a new amendment to the 301 (prior to the CIM18) we would add the versioning to that document

I meant November 24, 2021 in the last note