ADR - Release management change for Core Libraries

Decision Title

Release management change for Core Libraries

Status

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

Purpose

Change in release process for Core Libraries to have reduced impact on Code tagging process for milestone releases.

Problem statement

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.

Proposed solution

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

• Create independent versioning of Core Libraries.
• Do not cut a release branch at every release.
• Follow the following versioning strategy while rolling out new versions for Core Libraries.
  • Major Version
    • Create a new major version when the release contains Backward incompatible changes in Interfaces or Model classes.
    • For eg: id in Record class is changed to recordId.
  • Minor Version
    • Use minor version when additional methods are added to Interfaces, new fields are added to Model classes
    • Changes in versions of dependencies - Springboot, Jackson etc.
  • Patch Version
    • Increment patch version when Bug fixes or Security patches are applied to the Library.

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.

Consequences

• We retire the -rc* versioning strategy. We no longer create release candidates in Core Libraries.
• Every commit on the Core Library will end up creating a new version depending on the type of the change.

Target Release

M14

Owner

Please contact @krveduru