Commit 07d4c55e authored by Daniel Scholl's avatar Daniel Scholl
Browse files

Updated release management

parent f7e715f4
......@@ -56,17 +56,22 @@ v1 -------------------------------------------------------------
This style of release process then must also be somewhat aligned with a development process that can then be sufficiently tracked in order to be able to tell what the delta changes are between a release marker. Additionally, there starts to be a dependency tracking matrix then that must grow across infrastructure, middleware and services to be able to answer the following type of questions.
_Question:_ Can I update infrastructure v2 to v3 while running application code v2?
_Question:_ Can I run both application code v2 and v3 on infrastructure v3?
_Question:_ How do I manage infrastructure updates and possible breaking changes?
__Release Naming Strategy__
A release naming strategy needs to be in place with the OSDU forum and then can be extended for use by OSDU on Azure. A typical naming convention that is helpful is some type of [Semantic Versioning](https://semver.org/). Consider the following possible naming patterns.
`[Major]:[Minor]:[Patch]`
A naming pattern of this would require the OSDU forum to drop a release marker across the system and ensure that integration tests passed on the point in time timeline. Patch however tends to lead to the idea that individual services are being bug fixed and not all services might have the same patch version. This breaks the timeline model requirement of ensuring integration tests passed.
`[Horizon]:[Milestone]:[Iteration]`
A naming pattern might make sense based on the OSDU forum tracking to horizon's and milestones. Additionally though is the concept of what might be thought of as an Developer Iteration release.
Example 1:
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment