Release-Strategy.md

+# Versioning Strategy
+
+## Release Branches
+
+Each release of OSDU libraries and services will have a major/minor version pair (such as "1.0") that represents the release.
+Release numbers that match across different services are meant to be considered a package -- that is, they were released at the same time.
+The specific numbers in the version are increased with each release (in the normal way), but importantly are not synchronized to any other milestone name, including monikers such as "R3" or "M1".
+
+These releases are created as branches with the prefix `release/`, so that the release can be updated with additional patches later.
+Patches of this nature will not introduce new features, but instead will only apply bugfixes or minor updates.
+
+## Version Tags
+
+Each release branch will contain tags, one for each patch released under that version.
+The tags will be named with a `v` prefix and will repeat the version number (such as "v1.0.0").
+All release branches will have at least a ".0" patch, but may gain additional tags if patches are applied after branch creation.
+
+# Creation Process
+
+## Creating a new Release
+
+*Because the `release/*` and `v*` wildcards are protected, only maintainers can perform these tasks.*
+
+Before starting to release projects, create a release branch and initial tag for the [CI-CD Pipelines project](https://community.opengroup.org/osdu/platform/ci-cd-pipelines).
+This will create a stable pipeline reference, which is used later in other services.
+
+Then, for each service, create a branch based on the default branch, and name it appropriately ("release/X.Y").
+As the first commit to that branch, update the `.gitlab-ci.yml` file to reference the corresponding release tag of the CI-CD Pipelines projects.
+Once pushed, a full protected pipeline should execute on the release branch.
+*(If this does not happen, check your repository settings to ensure that `release/*` is a protected branch, and `v*` is a protected tag).*
+
+After the release pipeline passes and/or you are satisfied with the results, create a tag for the first patch ("vX.Y.0").
+Once created, the tag will run a full protected pipeline as well.
+
+## Creating a new Patch
+
+If a new patch is needed on a particular service, simply add the new commits to the release branch, either with cherry picks or merges.
+Then, wait for the new pipeline to succeed, and create a new tag on the branch incrementing the patch number (for example, "vX.Y.1").
+If new CI-CD Pipelines are needed for the patch, don't forget to update the `.gitlab-ci.yml` file to reference the new version of the CI-CD includes.
\ No newline at end of file