docs: release process documentation#168
docs: release process documentation#168PiotrKorkus wants to merge 2 commits intoeclipse-score:mainfrom
Conversation
|
The created documentation from the pull request is available at: docu-html |
There was a problem hiding this comment.
How is that aligned with https://eclipse-score.github.io/score/main/platform_management_plan/release_management.html, @aschemmel-tech for your info
There was a problem hiding this comment.
Linked docs do not tell anything about the process community needs to follow step by step to create S-CORE release. This is a technical guide we will use internally within reference integration team to align.
Then, it will be presented during Monday's tech alignment and once approved can be included into process_description.
There was a problem hiding this comment.
Integrating this in the release mgt process would be great once agreed.
| Once all Modules are merged with their *code freeze*, Module Codeowners create a tag on that exact hash following the S-CORE release process, | ||
| provide release notes to the ``score_platform`` team, and ensure that the new release is present in S-CORE's ``bazel_registry``. |
There was a problem hiding this comment.
PR feedback is not mentioned here at all. Modules will create tags without manual integration attempt into bazel registry.
There was a problem hiding this comment.
What kind of feedback we expect? Once the code-freeze is integrated successfully its just a simple swap hash -> version.
Internal release and push to bazel registry should happen without any unexpected issues at this point.
| If there are any issues, Module Codeowners can either push fixes to their **dedicated release** branch and update the hash in the PR accordingly, | ||
| or provide patches (see :ref:`ref_int_patching-label`). |
There was a problem hiding this comment.
depending on state etc, they can also push fixes on their main branch and retry the entire process
There was a problem hiding this comment.
what will this base off of? The last release? Then PRs will break due to incompatibilities?
There was a problem hiding this comment.
main branch is not the best choice in this situation as there might be some changes in the meantime which are not intended to be part of the release. This would break the whole idea of the code-freeze.
The base of the release branch is the code-freeze hash. Issues are either fixed on a release branch from code-freeze hash or patched in reference_integration repo.
apply suggestion Co-authored-by: Alexander Lanin <alex@lanin.de> Signed-off-by: Piotr Korkus <piotr.korkus.ext@qorix.ai>
4 participants
No description provided.