Conversation
PiotrKorkus
requested review from
PandaeDo,
aschemmel-tech,
masc2023 and
pahmann
as code owners
|
|
|
The created documentation from the pull request is available at: docu-html |
masc2023
left a comment
masc2023
left a comment
There was a problem hiding this comment.
Fine for me, beside the location of the content, see comment
PandaeDo
left a comment
PandaeDo
left a comment
There was a problem hiding this comment.
I really appreciate this description. And I suggest to merge it to have an initial version. But afterwards it shall be improved that somebody from outside can understand it better.
PiotrKorkus
force-pushed
the
piotrkorkus_release_process
branch
from
a5bf59e to
235e08a
Compare
LittleHuba
left a comment
LittleHuba
left a comment
There was a problem hiding this comment.
Will block this for the moment until I have reviewed it. Based on the description my approval is mandatory, so I enforce it with this block.
|
We will update the PR and therefore integrate it in the release management plan and also update the release process description. But please feel free to add your comments on this PR. I'll integrate them in the update as possible. |
PandaeDo
force-pushed
the
piotrkorkus_release_process
branch
from
5ca94fd to
47d2438
Compare
| #. Tooling release | ||
| #. Code freeze | ||
|
|
||
| **Integration phase (2 weeks) :** |
There was a problem hiding this comment.
Suggestion: Rename "Integration phase" to "Release phase"
Since we have continuous integration in place, calling this the "Integration phase" seems a bit inconsistent. Would it make more sense to rename it to "Release phase"? This would better reflect what's actually happening at this stage
| ----------- | ||
| At the end of development phase, each Module must provide a hash of the commit that represents a *code freeze* | ||
| and serves as a candidate for integration. The hash can be from the **main** or **dedicated release** branch. | ||
|
|
|
|
||
| Module Maintainers prepare a Pull Request to that branch with updates to the ``known_good.json`` file, | ||
| pointing to the hash of their *code freeze*. They may update other JSON fields for their Module as needed. | ||
| Automated workflows will build and test to provide clear feedback directly in the PR. |
There was a problem hiding this comment.
I'm wondering about the workflow here – if module maintainers have already specified the hash/version to use, what's the benefit of having them also create a PR? It seems like this could be streamlined by having the integration team handle PR creation, which would reduce review burden and help us move faster. Thoughts?
| ------------- | ||
|
|
||
| Project Leads create a branch ``release/version`` with new release notes in ``score_platform`` repository following template: :need:`doc__platform_release_note`. | ||
| Module Maintainers create a Pull Request to that branch with updates to the release notes, |
There was a problem hiding this comment.
is it "score" repository or score_platform ?
https://github.com/eclipse-score/score
9 participants
Has to be signed off by all CFT leads: