Skip to content

ADR - Update Info API to support core and CSP specific implementation version

Decision Title

Update Info API to support core and CSP specific implementation version

Status

  • Proposed
  • Approved
  • Implementing (incl. documenting)
  • Testing
  • Released

Context

An implementation of an OSDU service should be compliant towards OSDU specification i.e., the features and functionalities should be common across all the CSPs. However, CSP should have flexibility to introduce enhancements, bug fixes and security vulnerability fixes in the provider implementation modules independent of the OSDU release.

Problem statement

The structure of our OSDU service codebases is that we have Core module which contains the business logic for all the services, and we have the CSP modules where the CSP specific implementation is available. As part of the release process, the bug fixes or security patches can also be done at the CSP level. Let's say Azure has a bug fix or AWS has a bug fix. We shouldn't be incrementing the patch version for GCP / IBM as there are no changes for them to consume.

From the existing versioning strategy, we have ability to ship major, minor and patch releases at OSDU level where in new features are shipped as part of minor release and bug fixes / security patches can be shipped as part of patch release. With the introduction of CSP specific patch releases, we have introduced a new variable which a conventional SemVar based version cannot support.

Proposed solution

To support new release type (CSP Patch) and to be able to support different CSP releases (A major change in CSP implementation wherein, the CSP has decided to change the underlying technology used and is no longer compatible with previous releases), we need to introduce a new version that denotes the version for the implementation.

Scope

Given the definition or structure of SemVer where you can only hold three variables, minor, major and patch. We want to introduce a new versioning strategy where we will have a core version which will be the OSDU version, which denotes the major, minor and patch release, and then there will be a CSP version which will denote the CSP implementation version for that particular CSP. Let's say if CSP has a patch fix, the increment will increment the patch version for the CSP, not the actual OSDU version. So using that we will be able to increment as many releases as required for a given CSP.

Implications

Update Info API to add CSP version.

image

Example

image

Target Release

TBD

Owner

Please contact @krveduru

Edited by Naveen Ramachandraiah
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information