The rules for versioning YANG packages should ignore deviations and just follow simple rules based on additions/removals and changes to the module versions.
I think that tooling can probably do a separate diff comparing the resolved schema, but I don't think that is what should be reflected in the package versions.
This issue was raised by Joe:
An author of a new version of a package runs into another tooling need. If they’re hand-writing this, they would have no easy way to know if their package is BC or NBC relative to a previous version.
[RW] I should check the draft. I think that it should (i.e., need to) be possible to determine the new package version without building the schema. I.e., just looking at how the module versions have changed, or been added or removed. I.e., I think that the draft is probably currently wrong and we shouldn't give deviations any special consideration, it is just a YANG module. It may be that tooling does a more complete schema level comparison that should take deviations into account. This is possible an issue that might require some further thought/discussion.
They may be dealing with modules or other packages outside of their direct expertise. They need that tooling to resolve the schemas. To that end, maybe something like this in Section 6.1.1 to discourage any manual guessing of compatibility:
OLD:
When a package definition is updated, the version associated with the
package MUST be updated appropriately, taking into consideration the
scope of the changes as defined by the rules below.
NEW:
When a package definition is updated, the version associated with the
package MUST be updated appropriately, taking into consideration the
scope of the changes as defined by the rules below. Because several
of these rules depend on the resolved package schema of the prior
version rather than on the edited package file alone, authors are
expected to use package comparison tooling (Section 7.8) to determine
the correct classification. Manual classification of module and
deviation changes is not reliable and is not recommended.
[RW] I'm going to defer this change for the moment, and keep it is as part of the new issue.
The rules for versioning YANG packages should ignore deviations and just follow simple rules based on additions/removals and changes to the module versions.
I think that tooling can probably do a separate diff comparing the resolved schema, but I don't think that is what should be reflected in the package versions.
This issue was raised by Joe:
An author of a new version of a package runs into another tooling need. If they’re hand-writing this, they would have no easy way to know if their package is BC or NBC relative to a previous version.
[RW] I should check the draft. I think that it should (i.e., need to) be possible to determine the new package version without building the schema. I.e., just looking at how the module versions have changed, or been added or removed. I.e., I think that the draft is probably currently wrong and we shouldn't give deviations any special consideration, it is just a YANG module. It may be that tooling does a more complete schema level comparison that should take deviations into account. This is possible an issue that might require some further thought/discussion.
They may be dealing with modules or other packages outside of their direct expertise. They need that tooling to resolve the schemas. To that end, maybe something like this in Section 6.1.1 to discourage any manual guessing of compatibility:
OLD:
When a package definition is updated, the version associated with the
package MUST be updated appropriately, taking into consideration the
scope of the changes as defined by the rules below.
NEW:
When a package definition is updated, the version associated with the
package MUST be updated appropriately, taking into consideration the
scope of the changes as defined by the rules below. Because several
of these rules depend on the resolved package schema of the prior
version rather than on the edited package file alone, authors are
expected to use package comparison tooling (Section 7.8) to determine
the correct classification. Manual classification of module and
deviation changes is not reliable and is not recommended.
[RW] I'm going to defer this change for the moment, and keep it is as part of the new issue.