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?
There was a problem hiding this comment.
Where maintainers specified a version? With a PR we have clear message which version shall be used + approvals system out of the box.
How otherwise would you collect information about versions from each of the modules?
| ------------- | ||
|
|
||
| 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
There was a problem hiding this comment.
score repo is called score_platform
Line 15 in aebce36
| 4. Pre-Release Versions | ||
|
|
||
| * Use pre-release versions for features or fixes that are not yet ready for production. | ||
| * Format: MAJOR.MINOR.PATCH-<pre-release-tag>, e.g., 1.0.0-alpha, 1.0.0-beta. |
There was a problem hiding this comment.
| * Format: MAJOR.MINOR.PATCH-<pre-release-tag>, e.g., `1.0.0-alpha`, `1.0.0-beta`. |
| @@ -141,3 +144,202 @@ | |||
|
|
|||
| * Tag each release in the repository with the version number. | |||
| * Format: vMAJOR.MINOR.PATCH, e.g., v1.3.0. | |||
There was a problem hiding this comment.
| * Format: vMAJOR.MINOR.PATCH, e.g., v1.3.0. | |
| * Format: vMAJOR.MINOR.PATCH, e.g., `v1.3.0`. |
| Continuous Release Planning and Execution | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| Release interval (see :ref:`pmp_pm_release`) between S-CORE Product Increments can be divided into two phases: |
There was a problem hiding this comment.
| Release interval (see :ref:`pmp_pm_release`) between S-CORE Product Increments can be divided into two phases: | |
| Release interval (see :ref:`pmp_pm_release`) between S-CORE product increments can be divided into two phases: |
| **Integration phase (2 weeks) :** | ||
|
|
||
| #. Release branch creation | ||
| #. Integration of the Modules |
There was a problem hiding this comment.
| #. Integration of the Modules | |
| #. Integration of the modules |
| Common release requirements definition | ||
| -------------------------------------- | ||
|
|
||
| At the beginning, the overall scope and general requirements for the Modules are discussed during |
There was a problem hiding this comment.
| At the beginning, the overall scope and general requirements for the Modules are discussed during | |
| At the beginning, the overall scope and general requirements for the modules are discussed during |
| -------------------------------------- | ||
|
|
||
| At the beginning, the overall scope and general requirements for the Modules are discussed during | ||
| Release Team Meeting and agreed upon within the S-CORE community, providing clear goals for what must be achieved. |
There was a problem hiding this comment.
| Release Team Meeting and agreed upon within the S-CORE community, providing clear goals for what must be achieved. | |
| release team meeting and agreed upon within the S-CORE community, providing clear goals for what must be achieved. |
| --------------- | ||
|
|
||
| S-CORE tools, toolchains and other dependencies which are listed in the following Bazel MODULE files | ||
| located in reference integration repository: |
There was a problem hiding this comment.
Should we really list individual repos here? Requires update whenever a Repo is added/dropped. Maybe better link those.
There was a problem hiding this comment.
Im not listing individual repos, but maybe its better idea to say all module files located in bazel_common
| * ``bazel_common/score_modules_tooling.MODULE.bazel`` | ||
| * ``bazel_common/score_qnx_toolchains.MODULE.bazel`` | ||
| * ``bazel_common/score_rust_toolchains.MODULE.bazel`` | ||
|
|
There was a problem hiding this comment.
What about quality toolings like linters/sanitizers/ req. traceability tooling
So repos like score_cpp_policies, etc.
There was a problem hiding this comment.
I would refer to all of them as "tools" in general. Linters, traceability etc. are located currently in score_modules_tooling. If there are new tools that need to be added for the release they can be included in one of those files or new one within bazel_common/
| -------------------------- | ||
|
|
||
| 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. |
There was a problem hiding this comment.
Why do we work on PRs / Hashes here? I though we use bzl_mod in all repos. Then all that needs to be done is a check did bzl_mod version change in last 8 weeks. If not that module did not have an updates to contribute in the next release.
There was a problem hiding this comment.
Reference_integration goal is to provide continuous integration so every push to main branch of any module triggers an update in ref_int. If there are no issues the hash is bumped.
This way on main branch of ref_int we always have newest hash of the module that simply works here.
For the releases we want to switch to certain version from bazel registry. It doesnt have to be newest version. It is up to module owners to decide which version will be integrated for the score release. Thats why we need a PR with that information directly from the module owner.
There was a problem hiding this comment.
Hm okay, but shouldn't the rule rather be for the module owners: Do not push to bazel registry what shall not be integrated in proper releases (or if you to tag it "unsafe" or something alike)" 🤔
There was a problem hiding this comment.
Module owner can do the release whenever they want. They can create 5 releases during Development Phase - all are technically correct but they want to use middle one for release.
Same with bugfix releases, we need to fix something in the old release - which version of the module do we pick?
10 participants
Has to be signed off by all CFT leads: