Proposal for asychronous subsystem releases

I added a proposal for asynchronous subsystem releases to the document Tobias started on subsystem dependencies:

See the section Proposal: Asynchronous Releases at the end of the document, and please write your comments there in the document.

I’ve rewritten the proposal for asynchronous releases:

Please write your comments in the document.

1 Like

hi @benjamingeer apologies to read this only now, I don’t have the rights to edit the document and I also don’t see the comments of others.

We want to avoid situations like this: a breaking change is implemented in a lower component, followed by a number of non-breaking changes. For the components above, it is a priority to add support for these non-breaking changes, but the breaking change is a lower priority, so they cannot work on it in the near future. In the meantime, the DSP is stuck with an earlier version of the lower component.

Wasn’t it exactly the point of the versioning of interfaces? knora api v1 and v2 that are both in releases of the knora-api software, maybe it is too much work to maintain that on the whole chain? making one level depending on an interface version and not on a release version. So breaking changes would increase api versions and non breaking changes will first be implemented in the last api version and if not too costly, implemented in the others.

Right now there are not too many apps, we could think of a monitoring of api version used and deprecate as soon as a new one is out and remove them as early as possible (when nobody use them).

knora api v1 and v2 that are both in releases of the knora-api software

Knora API v2 is in beta, and has therefore had a number of breaking changes before we declare it stable.

Maintaining Knora API v1 and v2 in parallel is pretty easy, because they’re very different and they’re almost completely separate codebases. But I’m not sure I would want to maintain a lot of separate codebases with only small differences between them. In the future, we will have to decide on a design for deprecating features and replacing them with something else, while maintaining both the old and the new functionality, even if there are many changes like that.