diff --git a/process/folder_templates/modules/module_name/docs/release/release_note.rst b/process/folder_templates/modules/module_name/docs/release/release_note.rst index e2969a582a..9908a68d15 100644 --- a/process/folder_templates/modules/module_name/docs/release/release_note.rst +++ b/process/folder_templates/modules/module_name/docs/release/release_note.rst @@ -46,6 +46,12 @@ Release Note | This document provides an overview of the changes, improvements, and bug fixes included in the software module release version vX.Y.Z | as compared to the module's origin release (which is usually the previous release). | +| Disclaimer +| ---------- +| This release note does not "release for production", as it does not come with a safety argumentation and a performed safety assessment. +| The work products compiled in the safety package are created with care according to a process satisfying standards, but the S-CORE project, +| being a non-profit and open source organization, can not take over any liability for its content. +| | New Features | ------------ | diff --git a/process/process_areas/release_management/guidance/release_guideline.rst b/process/process_areas/release_management/guidance/release_guideline.rst index 10bb9bf9e8..fe9b739a74 100644 --- a/process/process_areas/release_management/guidance/release_guideline.rst +++ b/process/process_areas/release_management/guidance/release_guideline.rst @@ -18,7 +18,7 @@ Guideline .. gd_guidl:: Release Management Guideline :id: gd_guidl__rel_management :status: valid - :complies: std_req__iso26262__management_64131, std_req__iso26262__management_64132, std_req__iso26262__management_64133, std_req__iso26262__management_64135 + :complies: std_req__iso26262__management_64131, std_req__iso26262__management_64132, std_req__iso26262__management_64133, std_req__iso26262__management_64134, std_req__iso26262__management_64135 .. _workflow_release: @@ -27,7 +27,7 @@ Software Module Release 1. **Repository Management**: - * Each software module is contained in its own GitHub repository. + * Each software module is contained in its own repository. * Ensure that the repository follows the standard naming conventions and structure. 2. **Release Planning**: @@ -48,12 +48,13 @@ Software Module Release * Prepare release notes documenting the changes, improvements, and bug fixes. * Check if all planned configuration items are in correct state (i.e. work products are valid, external libraries/tools are used in the correct released version). * Ensure the module's safety package is available and complete. - * Tag the release in the GitHub repository. + * Tag the release in the repository. 5. **Release Execution**: - * Create a release in the GitHub repository release branch and attach the release notes. For this consider the `GitHub Howto Release `_ + * Create a release in the repository release branch and attach the release notes. For this consider the `Howto Release `_ * Notify the project lead circle about the release for approval. + * One of the project leads will give a review approval for the release note in the versioning tool, which is equivalent to his signing the release. Platform Release @@ -84,12 +85,13 @@ Platform Release * Prepare platform release notes summarizing the updates from all integrated software modules. * Check if all planned configuration items are in correct state (i.e. work products are valid, external libraries/tools are used in the correct released version). * Ensure the relevant safety packages are available and complete. - * Tag the platform release in the GitHub repository. + * Tag the platform release in the repository. 5. **Release Execution**: - * Create a release in the GitHub repository release branch and attach the platform release notes. For this consider the `GitHub Howto Release `_ + * Create a release in the repository release branch and attach the platform release notes. For this consider the `Howto Release `_ * Notify the project lead circle about the release for approval. + * One of the project leads will give a review approval for the release note in the versioning tool, which is equivalent to his signing the release. * Publish within Eclipse SDV. @@ -98,7 +100,7 @@ Tracking and Communication 1. **Tracking**: - * Use the github project management tools to track the progress of software module releases and the platform release. + * Use the project management tools to track the progress of software module releases and the platform release. * Maintain a release calendar to visualize the timelines and milestones. 2. **Communication**: diff --git a/process/process_areas/release_management/guidance/release_templates.rst b/process/process_areas/release_management/guidance/release_templates.rst index 40798182c5..0d71689dd3 100644 --- a/process/process_areas/release_management/guidance/release_templates.rst +++ b/process/process_areas/release_management/guidance/release_templates.rst @@ -32,6 +32,12 @@ Templates | This document provides an overview of the changes, improvements, and bug fixes included in the platform release version vX.Y.Z | as compared to the platform origin release (which is usually the previous release). | + | Disclaimer + | ---------- + | This release note does not "release for production", as it does not come with a safety argumentation and a performed safety assessment. + | The work products compiled in the safety package are created with care according to a process satisfying standards, but the S-CORE project, + | being a non-profit and open source organization, can not take over any liability for its content. + | | New Features | ------------ | - **Feature 1**: Brief description of the new feature. @@ -99,10 +105,10 @@ Templates | ------------------------------------------------------- | | 1. Link this issue to the correct milestone and assign to the technical lead - | 2. Check respective Verification report on the release candidate's github tag + | 2. Check respective Verification report on the release candidate's baseline | 3. Check bugfixes or justify failed tests | 4. Check the safety package completeness (includes "valid" documents and work products status, supported by the safety manager) | 5. Create/update the release note (pull request to close this issue) - | 6. Document safety manager's "recommendation to release" by asking his GitHub review approval of the release note - | 7. Create the "release" in GitHub according to :need:`gd_guidl__rel_management` + | 6. Document project manager's consent by asking review approval of the release note + | 7. Create the "release" in version management tool according to :need:`gd_guidl__rel_management` | 8. Merge PR and close this issue to complete the release