Approved for Azure
Release management change for Core Libraries
Change in release process for Core Libraries to have reduced impact on Code tagging process for milestone releases.
Right before the code freeze, we have core library and all services upgrades during that milestone. If we have a major upgrade e.g. spring boot update or Jackson Library gets upgraded from some older to new version, because the services have been working on some older version of core libraries, we will see that there will be a compile time errors or runtime errors on all the services in most of the time. That will actually impact the stability of the system, because now you stop all your development work in order to sanitize the release branch so that the service is up and running and all the items are passing being an additional overhead that we are taking.
Core libraries are not something that are shipped to the customers and are used internally within the OSDU community internally. Hence, they do not need to follow the milestone versioning.
We can avoid the above mentioned of upgrading library versions in services at every release by maintaining the following versioning strategy for Core Libraries
id
in Record
class is changed to recordId
.With this approach we avoid patching core libraries right before the release and thereby, reduce the amount of time spent on Stabilizing the service during code tagging process.
M14
Please contact @krveduru
Update Info API to support core and CSP specific implementation version
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.
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.
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.
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.
Update Info API to add CSP version.
TBD
Please contact @krveduru
Swagger Sanity Phase 2: Using springdoc-openapi for swaggers APIs
The swagger for all services is in version 3 already.
The cost of maintenance of the swagger doc is high. We have stale swaggers in the system already.
We have the following frameworks that will help lower the cost of upkeep of swagger.
springdoc-openapi
springdoc-openapi-webflux-ui
The above effort will encapsulate the following
TBD
**1. How will we manage migration to next generation of swaggers, when available. ** We will count on Spring Boot's adaptation of the next generation to be back compatible.
**2. Will there be regressions in the existing experience? ** No, as specified in the Scope.
Please contact @komakkar
Rene von Borstel [EPAM] (07e1040d) at 30 Aug 17:13
Merge branch 'secret-groups' into 'master'
... and 1 more commit
Rene von Borstel [EPAM] (90993758) at 18 Aug 16:52
Upload New File
Rene von Borstel [EPAM] (8bb82785) at 18 Aug 14:08
Upload New File
Rene von Borstel [EPAM] (888a372f) at 18 Aug 14:08
Upload New File
Rene von Borstel [EPAM] (e4c99c79) at 16 Aug 16:04
This reverts merge request !41
Rene von Borstel [EPAM] (e416dd45) at 16 Aug 16:04
Merge branch 'revert-7eea3c2e' into 'master'
... and 1 more commit
This reverts merge request !41
Rene von Borstel [EPAM] (e4c99c79) at 16 Aug 16:02
Revert "Merge branch 'rene_von_borstel-master-patch-56089' into 'ma...
Rene von Borstel [EPAM] (14b75a96) at 16 Aug 16:00
Rene von Borstel [EPAM] (7eea3c2e) at 16 Aug 16:00
Merge branch 'rene_von_borstel-master-patch-56089' into 'master'
... and 1 more commit