Currently, when a new version of a DTDL interface is created (e.g. dtmi:com:example:MyModel;1 --> dtmi:com:example:MyModel;2) there are many constraints on what can change from version to version. Most notably, in almost all cases, nothing can be removed from an existing interface when going from vN to vN+1. In practice, this causes deprecated and unused cruft in interfaces that can never be removed short of starting over with a completely different interface.
This change, to remove the additivity constraint, intends to put control for what changes in an interface from version to version in the hands of the interface author. If the interface author is working closely with the code that implements and/or consumes the interface, then any number of changes may be appropriate. If the interface author is publishing an interface for use across multiple devices or digital twins and/or multiple solutions, compatible changes from version to version may be more appropriate.
Currently, when a new version of a DTDL interface is created (e.g. dtmi:com:example:MyModel;1 --> dtmi:com:example:MyModel;2) there are many constraints on what can change from version to version. Most notably, in almost all cases, nothing can be removed from an existing interface when going from vN to vN+1. In practice, this causes deprecated and unused cruft in interfaces that can never be removed short of starting over with a completely different interface.
This change, to remove the additivity constraint, intends to put control for what changes in an interface from version to version in the hands of the interface author. If the interface author is working closely with the code that implements and/or consumes the interface, then any number of changes may be appropriate. If the interface author is publishing an interface for use across multiple devices or digital twins and/or multiple solutions, compatible changes from version to version may be more appropriate.