Adds guide about release#226
Conversation
Signed-off-by: Manjinder <manjinder.b.singh@capgemini.com>
|
Merging this PR into custom branch, so that people can review it over there. |
nilanjan-samajdar
left a comment
nilanjan-samajdar
left a comment
There was a problem hiding this comment.
Please merge comments in #223
| @@ -0,0 +1,173 @@ | |||
| # Release Process | |||
|
|
|||
| This document outlines the comprehensive release process for the project, including versioning, workflow, and deliverables. It applies to the following components: | |||
There was a problem hiding this comment.
Please add the following points -
The 'Sandbox' release corresponds to a specific version of the MARGO Specification, including the OpenAPI swagger definition of the specification, as mentioned in the release notes.
The release may contain SUPs (features) or bug-fixes / improvement suggestions raised by the community, The release notes will have a list of submissions which are part of the release. This list may be auto-generated from the comments in the push-requests (PR) that were approved for the release.
| Example transitions: | ||
| - `1.0.0` + `feat: add new endpoint` → `1.1.0` | ||
| - `1.1.0` + `fix: resolve bug` → `1.1.1` | ||
| - `1.1.1` + `feat: change API (BREAKING CHANGE)` → `2.0.0` |
There was a problem hiding this comment.
1.0.0+feat: add new endpoint→1.1.0
This should be the addition of a SUP or a change in MARGO API for alignment to a SUP
1.1.1+feat: change API (BREAKING CHANGE)→2.0.0
A Major change involving a bunch of SUPs or a change in the MARGO API which may not be backward compatible
| - Merge all approved changes into `develop`. | ||
| - Merge the `develop` into `main` branch. Ensure all test cases pass. | ||
| 3. **Create Tag**: Create a Git tag from `main` following SemVer (e.g., `git tag v1.2.3`). | ||
| 4. **Run Tests**: Ensure all test cases pass, including integration, end-to-end tests and the conformance as well?? NEED REVIEW! |
There was a problem hiding this comment.
Yes, a change in API should have a change in Conformance Test as well, at least this should be part of the review check-list
| 1. **Declare Code Freeze**: Announce code freeze on the `develop` branch via discussion channels (e.g., Teams TWG Main). Freeze window should be 1-2 weeks to stabilize. | ||
| 2. **Merge Changes**: | ||
| - Merge all approved changes into `develop`. | ||
| - Merge the `develop` into `main` branch. Ensure all test cases pass. |
There was a problem hiding this comment.
Mention -
PR should mention the nature of changes, including corresponding PR (if applicable) or Issue number (for bugs/improvements).
| - Format: `type(scope): description` | ||
| - Common types: `feat` (new feature), `fix` (bug fix), `docs` (documentation), `refactor` (code change), `test` (testing), `chore` (maintenance). | ||
| - Scopes: Optional, e.g., `api`, `cli`, `helm`. | ||
| - For breaking changes: Include `BREAKING CHANGE:` in the commit footer, e.g.: |
There was a problem hiding this comment.
Lets add a commit format in the Github
git config commit.template /absolute/path/to/file
There was a problem hiding this comment.
We have added commitlint in the CI pipeline that enforces this to some extent although doesn't define what should go into the subjective message.
2 participants
No description provided.