GSoSD review question #10: What kinds of backwards compatibility should Arrowhead version 5 offer with regards to version 4?

[jerkerdelsing]

Implementation backward compatibility will be important long term.

The current strategy is that we are moving to the next major version 5.0
A v5.1 will be release based on a new core system being added or a major update of one of the release core systems.
A v5.x.y release is bug fixes.

A to me reasonable suggestion is that backwards compatibility should be available for:
v5.0 shall be backward compatible with v4.6
v5.1 should be backward compatible with v4.6 and v5.0
v5.2 should be backward compatible with v4.6, v5.0 and v5.1
v5.3 should be backward compatible with v5.0, v5.1 and v5.3

[rbocsi]

Unfortunately, v5.0 CANNOT be compatible with 4.6, mostly because of database separation. In 4.6 every core and support system use a shared database (with foreign keys to connect the entities to each other), and the REST API uses the database ids as input parameters. For example, to add a new authorization rule you need to specify the database id of the consumer, provider systems, the id of the service description and the id of the interface (4 integers).

In v5.0, we will use unique identifiers (names) for specifying a system, a service definition, a service instance in the REST API (or in other interfaces). This makes database separation possible, and for an additional improvement it makes possible to create authorization rules for systems that is not registered yet for example.

So, in the previous example instead of 4 integers we will use 4 strings. This breaks backward compatibility.

But, we agree with you that from v5.0, the next version should be compatible with v5.0 (and so on).

[jerkerdelsing]

Jerker to summarise the discussion into the GSoSD.

[jerkerdelsing]

Introduced into the GSoSD