|
|
# Versioning Strategy
|
|
|
|
|
|
**Latest version of the strategy document - [click here](http://osdu.projects.opengroup.org/pmc/work-products/versioning-strategy)**
|
|
|
**Latest version of the strategy document -** [**click here**](http://osdu.projects.opengroup.org/pmc/work-products/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".
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
|
|
|
- [R2 Gitlab milestone - 0.3.0](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-0.3-Tagging-Notes)
|
|
|
- [R3 Milestone 1/2 deliverables - 0.4.0](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-0.4-Tagging-Notes)
|
|
|
- [R3 Milestone 3 deliverables - 0.5.0](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-0.5-Tagging-Notes)
|
|
|
- [R3 Milestone 4 deliverables - 0.7.0](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-0.7-Tagging-Notes)
|
|
|
- [R3 Milestone 5 deliverables - 0.8.0](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-0.8-Tagging-Notes)
|
|
|
- [R3 Milestone 6 deliverables - 0.9.0](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-0.9-Tagging-Notes)
|
|
|
* [R2 Gitlab milestone - 0.3.0](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-0.3-Tagging-Notes)
|
|
|
* [R3 Milestone 1/2 deliverables - 0.4.0](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-0.4-Tagging-Notes)
|
|
|
* [R3 Milestone 3 deliverables - 0.5.0](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-0.5-Tagging-Notes)
|
|
|
* [R3 Milestone 4 deliverables - 0.7.0](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-0.7-Tagging-Notes)
|
|
|
* [R3 Milestone 5 deliverables - 0.8.0](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-0.8-Tagging-Notes)
|
|
|
* [R3 Milestone 6 deliverables - 0.9.0](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-0.9-Tagging-Notes)
|
|
|
|
|
|
## Release Notes
|
|
|
|
|
|
* [R3 Milestone 6](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/Release-Notes#m6-july-x-2021)
|
|
|
|
|
|
## Development timeline for milestones
|
|
|
|
|
|
Each OSDU milestone starts with about 1.5 months of development, followed by the code tagging process, deployment into pre shipping environment by CSP teams, and validation in pre shipping environment.
|
|
|
|
|
|
![OSDUMilestoneRelease](uploads/703b4ea8c804cc001505221ee24058c2/OSDUMilestoneRelease.png)
|
|
|
![OSDUMilestoneRelease](/osdu/governance/project-management-committee/-/wikis/uploads/703b4ea8c804cc001505221ee24058c2/OSDUMilestoneRelease.png)
|
|
|
|
|
|
Below is the current planned date for upcoming OSDU milestone releases. Note that:
|
|
|
- Code freeze date is for development teams to complete the new function development and integration in this release.
|
|
|
- Public release date is after the validation from pre shipping team. The date may change depending on the validation results.
|
|
|
|
|
|
|Milestones|Code freeze date for Dev teams|Public release date|
|
|
|
|----------|------------------------------|-------------------|
|
|
|
|M5 |Apr 9, 2021 |May 2021 |
|
|
|
|M6 |May 28, 2021 (end of May) |Jun 25, 2021 |
|
|
|
|M7 |Jul 16, 2021 (mid of Jul) |Aug 13, 2021 |
|
|
|
|M8 |Aug 27, 2021 (end of Aug) |Sep 24, 2021 |
|
|
|
* Code freeze date is for development teams to complete the new function development and integration in this release.
|
|
|
* Public release date is after the validation from pre shipping team. The date may change depending on the validation results.
|
|
|
|
|
|
Milestones Code freeze date for Dev teams Public release date M5 Apr 9, 2021 May 2021 M6 May 28, 2021 (end of May) Jun 25, 2021 M7 Jul 16, 2021 (mid of Jul) Aug 13, 2021 M8 Aug 27, 2021 (end of Aug) Sep 24, 2021
|
|
|
|
|
|
# Creation Process
|
|
|
|
|
|
## Creating a new Release
|
|
|
|
|
|
*Because the `release/*` and `v*` wildcards are protected, only maintainers can perform these tasks.*
|
|
|
_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.
|
|
|
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).*
|
|
|
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.
|
|
|
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. |
|
|
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 |