Skip to content

Audit action correction: release no production #108

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
aschemmel-tech merged 1 commit into from
Jul 15, 2025
Merged

Audit action correction: release no production #108

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions process/folder_templates/modules/module_name/docs/release/release_note.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
| ------------
|
Expand Down
16 changes: 9 additions & 7 deletions process/process_areas/release_management/guidance/release_guideline.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:

Expand All @@ -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**:
Expand All @@ -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 <https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository/>`_
* Create a release in the repository release branch and attach the release notes. For this consider the `Howto Release <https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository/>`_
* 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
Expand Down Expand Up @@ -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 <https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository/>`_
* Create a release in the repository release branch and attach the platform release notes. For this consider the `Howto Release <https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository/>`_
* 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.


Expand All @@ -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**:
Expand Down
12 changes: 9 additions & 3 deletions process/process_areas/release_management/guidance/release_templates.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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