Figure out whether changing the imports constitute a BC or NBC change

[rgwilton]

What happens if an import becomes more/less restrictive.

Previously proposed text by Balazs:

     Removing the import-versions statements as long as at least one of the 
     original statements remain, is backwards compatible.
     Changing the version-clause to prohibit some previously allowed 
     versions and NOT to allow any new import-candidates is BC.
     Adding import-versions statements or changing the version-clause to 
     allow new import-candidates is risky. It may or may not be compatible 
     depending on the compatibility of the imported module, on how the 
     import is used etc. It gets to complicated, so lets call it NBC. 

[jsterne]

Part of this depends on whether we want to assume that most changes don't break import compatibility vs being strict. I agree with Balazs if we are trying to be strict. Any reduction in the list of acceptable import versions is safe (BC) as long as at least one remains. We know all the versions specified are acceptable so a subset is also acceptable. But increasing the set of versions, or eliminating the import versions altogether is not safe. That could result in a version being included that breaks things. But do we want to be strict here? Or do we want to assume these types of changes don't break import compatibility? In theory the author making the change to the import-versions should analyze the impact and determine if it can result in something being broken right? If it can actually break something, then it is a bug in their YANG module and they should fix the import-versions. But besides that, changing the import-versions in module B can potentially break things for module A that imports module B. So I can see why Balasz is leaning towards making that an NBC change. Jason From: Robert Wilton <notifications@github.com> Sent: Wednesday, February 27, 2019 9:31 AM To: netmod-wg/yang-ver-dt <yang-ver-dt@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: [netmod-wg/yang-ver-dt] Figure out whether changing the imports constitute a BC or NBC change (#4) What happens if an import becomes more/less restrictive. Previously proposed text by Balazs: Removing the import-versions statements as long as at least one of the original statements remain, is backwards compatible. Changing the version-clause to prohibit some previously allowed versions and NOT to allow any new import-candidates is BC. Adding import-versions statements or changing the version-clause to allow new import-candidates is risky. It may or may not be compatible depending on the compatibility of the imported module, on how the import is used etc. It gets to complicated, so lets call it NBC. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#4>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AScCf9N2_jCn9z9Kxj9CBjtfJLXHJ_mpks5vRpaegaJpZM4bUqP7>.

[Reshad-Rahman]

Even increasing the set of versions can be safe if it's adding BC versions, e.g. going from 1.1.0 to 1.1.0-1.2.0 is BC?

As others have mentioned, when we're adding NBC versions to the set, we don't know the impact on the importing module. Systematically making that NBC is the simple solution but can be incorrect. Imagine a type in ietf-xxx-types.yang being changed in a backwards incompatible way and lots of modules having to go NBC version change even if the type which got changed in NBC way isn't used by the importing modules.

[rgwilton]

I think that versioning should be considered at two levels: (i) on an individual module file basis (ii) at the schema/package level.

At the individual module file level; adding, changing, or removing a module is a backwards-compatible-change, since the change in itself doesn't change the module schema.

Of course, the imported module might have changed in a NBC way between revisions, but this must be detected as the package level.

Say an imported module exists in versions 1.0.0 and 2.0.0 with NBC changes in a used grouping. If an importing module specified "1.0.0 or derived" then it could end up with "1.0.0 or 2.0.0". Updating it to "2.0.0 or derived" doesn't necessarily change the schema because 2.0.0. might have been previously used. Therefore the version of a module shouldn't be affected by the version of its imports - we should leave that problem to be solved at a higher layer, i.e. the packages draft, which I believe already solves this problem.

Hence, to close this issue I propose that we add a sentence to section 3.1.1 stating that add, removing, or changing an import statement (including add,changing, or removing a restriction on which specific revisions may be imported) is a backwards compatible change.

[Reshad-Rahman]

Notes from virtual interim on Dec 14th 2020:

For #4, a change to the import statement is considered as backwards-compatible. There were some discussions as to whether there should be exceptions, but the semver draft already allows the major version to be bumped when all changed made are BC.

Under some circumstances (e.g., to avoid adding a "compatible"
modifier) an artifact author MAY also update the MAJOR version
when the only changes are backwards-compatible.

[jsterne]

We need to add text to section 3.1.1 to indicate import changes are BC

[jsterne]

If we move to import by revision-or-derived to being less strict, then that also lends weight to this simply being BC.

[jsterne]

Updated text added to section 3.1.1 of PR#157