Add the release strategy document #218
Conversation
kazydek
requested review from
bszwarc,
klaudiagrz and
tomekpapiernik
as code owners
|
|
||
| For release versioning, Kyma follows the approach similar to [Semantic Versioning](https://semver.org/). However, while Semantic Versioning focuses on APIs, the release process for Kyma refers to the complete Kyma deliverable. Despite this difference, Kyma follows the same release types: | ||
|
|
||
| - **MAJOR** release to introduce breaking changes |
There was a problem hiding this comment.
Saying "release" in these cases is redundant as the previous sentence says:
Kyma follows the same release types:
I'd remove "release" from all 3 bullet points.
I think presenting this information in a chart format would also work nicely.
There was a problem hiding this comment.
Chart:
| Release type | Scope |
|---|---|
| MAJOR | Introduces breaking changes |
| MINOR | Introduce a new functionality in a planned schedule. |
| PATCH hot.fix |
Introduce a backwards-compatible bug fix as an unscheduled release. |
| - **MINOR** release to introduce a new functionality in a planned schedule | ||
| - **PATCH** release or a **hot.fix** to introduce a backwards-compatible bug fix as an unscheduled release | ||
|
|
||
| >**NOTE:** **Major version zero** refers to the rapid product development that is not production-ready yet. That is why, major changes introduced before the 1.0 release, like in versions 0.5 or 0.6, are not represented as increases in the major version number. |
There was a problem hiding this comment.
I don't understand this note. The message is not clear and the punctuation is confusing. I think this should be re-phrased.
There was a problem hiding this comment.
Ok, I changed the sentence a bit.
|
|
||
| ### Function freeze | ||
|
|
||
| The function freeze refers to the point in time after which you cannot merge new features to the release branch. |
There was a problem hiding this comment.
| The function freeze refers to the point in time after which you cannot merge new features to the release branch. | |
| The "Function freeze" refers to the point in time after which you cannot merge new features to the release branch. |
There was a problem hiding this comment.
I changed it into:
The function freeze term refers to the point in time after which you cannot merge new features to the release branch.
|
|
||
| ### Epics and user stories | ||
|
|
||
| The functional implementations that are included in the release are documented as GitHub issues. A given team completes issues according to the Definition of Done (DoD) checklist that is applicable to the product and the team who implements them. Other developers must review your issue and a corresponding Product Owner, Capability Owner, or Quality Owner must accept it. |
There was a problem hiding this comment.
| The functional implementations that are included in the release are documented as GitHub issues. A given team completes issues according to the Definition of Done (DoD) checklist that is applicable to the product and the team who implements them. Other developers must review your issue and a corresponding Product Owner, Capability Owner, or Quality Owner must accept it. | |
| The functional implementations that are included in the release are documented as GitHub issues. A given team completes issues according to the Definition of Done (DoD) checklist that is applicable to the product and the team who implements them. Other developers must review the issue and a corresponding Product Owner, Capability Owner, or Quality Owner must accept it. |
|
|
||
| All Kyma organization members involved in the release process comply with contribution rules defined for Kyma and ensure that all checks built into the continuous integration process pass. These requirements represent the absolute minimal acceptance criteria needed for a release from a compliance perspective. These rules can change as Kyma approaches the 1.0 release. | ||
|
|
||
| Additional, manual pre-release verification needs to be done for the following: |
There was a problem hiding this comment.
| Additional, manual pre-release verification needs to be done for the following: | |
| Additionaly, manual pre-release verification must cover these areas: |
| The Head of Capabilities coordinates the product planning, following the planning cycles for the Kyma development. | ||
|
|
||
| ### Planning end | ||
| After completing the planning process, the theme and expected scope of the release is clear. All development teams know what they have to work on for this release and commit to completing this work. |
There was a problem hiding this comment.
| After completing the planning process, the theme and expected scope of the release is clear. All development teams know what they have to work on for this release and commit to completing this work. | |
| After completing the planning process, the theme and expected scope of the release is clear. All development teams know what they have to work on for the release. |
There was a problem hiding this comment.
and commit to completing this work. doesn't really make much sense here imo
| The Release Manager and the Product Leadership decide to publish the release, based on the status and readiness of the developed functionality. The Release Manager communicates this decision before the release execution starts. | ||
|
|
||
| ### Release execution | ||
| The Release Engineer executes the release at any time of producing the release artifact. This could result in a release candidate or a final release that is not an automated nightly or weekly build. The release execution begins when the process starts and finishes after publishing all artifacts and the related documentation. |
There was a problem hiding this comment.
I don't think I understand this paragraph. You say that the release engineer "executes" the release, then you say that this "could result". Then there's execution begins when the process starts and finishes.
:(
| ### Release execution | ||
| The Release Engineer executes the release at any time of producing the release artifact. This could result in a release candidate or a final release that is not an automated nightly or weekly build. The release execution begins when the process starts and finishes after publishing all artifacts and the related documentation. | ||
|
|
||
| During the execution of a release, Kyma developers run all end-to-end test scenarios. If any single scenario fails, the Release Engineer cannot publish the release. |
There was a problem hiding this comment.
| During the execution of a release, Kyma developers run all end-to-end test scenarios. If any single scenario fails, the Release Engineer cannot publish the release. | |
| During the execution of a release, Kyma developers run all end-to-end test scenarios. If any scenario fails, the Release Engineer cannot publish the release. |
| ## Release scope | ||
| For each of the planning periods described in the release schedule, GitHub epics and issues define and document the release scope with regards to functionality, corrections, and even non-functional requirements. The collection of all documented issues within a release represents the expected scope of that release that the whole organization and all teams define and commit to. The corresponding release in ZenHub identifies all issues and epics that fall under the final release scope. | ||
|
|
||
| When planning the release scope, all persons involved in the release must take into consideration the GDPR requirements when processing or storing personal data. |
There was a problem hiding this comment.
| When planning the release scope, all persons involved in the release must take into consideration the GDPR requirements when processing or storing personal data. | |
| When planning the release scope, all persons involved in the release must take the GDPR requirements into consideration when processing or storing personal data. |
|
|
||
| When planning the release scope, all persons involved in the release must take into consideration the GDPR requirements when processing or storing personal data. | ||
|
|
||
| ### Down-porting |
There was a problem hiding this comment.
I think we should use the term "downgrade". "Downporting" doesn't really have a definition and is used scarcely.
vs
| When planning the release scope, all persons involved in the release must take into consideration the GDPR requirements when processing or storing personal data. | ||
|
|
||
| ### Down-porting | ||
| There is no guaranteed bug fix down-porting for the Kyma project. The default strategy is to upgrade to the latest version. All changes must align with the Kyma upgrade strategy. |
There was a problem hiding this comment.
Does it mean that there's is no established strategy of downgrading that is supposed to fix bugs?
There was a problem hiding this comment.
I rephrased that. Hope it is clear now.
|
|
||
| ### Epics and user stories | ||
|
|
||
| The functional implementations that are included in the release are documented as GitHub issues. A given team completes issues according to the Definition of Done (DoD) checklist that is applicable to the product and the team who implements them. Other developers must review your issue and a corresponding Product Owner, Capability Owner, or Quality Owner must accept it. |
There was a problem hiding this comment.
Since this is targeting external contributions, we should probably leave out teams from this, so I would suggest to rephrase to something like:
The functional implementations that are included in the release are documented as GitHub issues. A given maintainer completes issues bound by the contribution license and following the contribution guidelines. All changes go through Continuous Integration and other reviews before being merged to master.
If so, please also link the license and guidelines.
There was a problem hiding this comment.
But! changed it a bit so pls take a look :)
|
|
||
| The functional implementations that are included in the release are documented as GitHub issues. A given team completes issues according to the Definition of Done (DoD) checklist that is applicable to the product and the team who implements them. Other developers must review your issue and a corresponding Product Owner, Capability Owner, or Quality Owner must accept it. | ||
|
|
||
| You can close an epic or an issue if the implemented functionality meets the respective DoD requirements. These include, but are not limited to, the following points: |
There was a problem hiding this comment.
idem
You can close an epic or an issue if the implemented functionality has been merged to master taking care to follow all contribution rules and guidelines. These include, but are not limited to, the following points:
| - Automated unit and end-to-end tests verify this functionality. | ||
| - This functionality is documented. | ||
|
|
||
| To accept an issue which does not comply with these requirements, you must receive an exceptional approval from the Product Owner and the Release Manager. |
There was a problem hiding this comment.
I would probably remove this sentence completely. External contributors shall always comply with the contribution guidelines with no exceptions.
|
|
||
| ### Test coverage | ||
|
|
||
| In Kyma, we follow the accepted test strategy according to which you can verify all functionalities through automated testing that you execute either through the CI or the release pipeline. |
There was a problem hiding this comment.
remove accepted and link to the test strategy (as soon as it is finalized)
|
|
||
| In Kyma, we follow the accepted test strategy according to which you can verify all functionalities through automated testing that you execute either through the CI or the release pipeline. | ||
|
|
||
| The Kyma team must provide the highest possible test coverage to minimize any potential risks and ensure the release is functional and stable. |
There was a problem hiding this comment.
No Kyma team. All contributors / maintainers / the community / any single contribution ?
| ### Development start | ||
| After completing the planning, the Head of Capabilities explicitly hands over the release to the engineering teams during the handover meeting. At this point, the development phase of the new release officially starts. | ||
|
|
||
| The Kyma developers add new release features to the `master` branch of the Kyma repositories. |
There was a problem hiding this comment.
I would drop this line completely... The development process in GitHub is clear, and this could even confuse more than help people...
| ### Release execution | ||
| The Release Engineer executes the release at any time of producing the release artifact. This could result in a release candidate or a final release that is not an automated nightly or weekly build. The release execution begins when the process starts and finishes after publishing all artifacts and the related documentation. | ||
|
|
||
| During the execution of a release, Kyma developers run all end-to-end test scenarios. If any single scenario fails, the Release Engineer cannot publish the release. |
There was a problem hiding this comment.
Maybe something like
During the execution of a release, all automated end-to-end test scenarios are validated. If a single scenario fails, the release process automatically stops and no release is possible.
|
|
||
| During the execution of a release, Kyma developers run all end-to-end test scenarios. If any single scenario fails, the Release Engineer cannot publish the release. | ||
|
|
||
| The Release Manager or Kyma developers notify the Kyma community when the release candidate is available. They pass this information to the public on Slack, requesting the community to validate and provide their short-term feedback. The deadline for the feedback is the day before the planned final release. Ideally, the final release is the same as the last release candidate, avoiding any additional changes. If the Kyma developers identify any release-related issues, they asses them and decide together with the Release Manager if they must fix them and produce a new release candidate. |
There was a problem hiding this comment.
First line:
Through the SIG Core, the Kyma community will be notified
Instead of "If the Kyma developers identify any release-related issues..."
If any release-related issue is reported, it will be assessed to determine whether it would constitute a blocker for the release, in which case the Release Manager will be involved in the decision how to proceed. This will also be communicated to the SIG Core.
There was a problem hiding this comment.
I rephrased that a bit - pls verify if that version is fine :)
| ### Release publishing | ||
| The final release is available in the GitHub releases, including the installation instructions. It also includes the complete changelog that lists all pull requests merged into this release. | ||
|
|
||
| A Technical Writer publishes the blog post on the public Kyma website to announce the release. The post includes release notes prepared based on the input from the Product Owners. |
There was a problem hiding this comment.
Please add:
Any known issues will also be documented in the release notes.
| ### Down-porting | ||
| There is no guaranteed bug fix down-porting for the Kyma project. The default strategy is to upgrade to the latest version. All changes must align with the Kyma upgrade strategy. | ||
|
|
||
| The Kyma team does not plan to provide any patch releases before the first 1.0 production release and encourages the community to always upgrade to the latest release. |
There was a problem hiding this comment.
Replace "The Kyma team" with "The project Kyma"
| The Release Manager and the Product Leadership decide to publish the release, based on the status and readiness of the developed functionality. The Release Manager communicates this decision before the release execution starts. | ||
|
|
||
| ### Release execution | ||
| The release execution is a manual process and is not part of an automated nightly or weekly build. It begins when the Release Engineer creates a release branch with all release artifacts. The process finishes after publishing both the artifacts and the related documentation as a release candidate that can be promoted as a final release. |
There was a problem hiding this comment.
| The release execution is a manual process and is not part of an automated nightly or weekly build. It begins when the Release Engineer creates a release branch with all release artifacts. The process finishes after publishing both the artifacts and the related documentation as a release candidate that can be promoted as a final release. | |
| The release execution is a manual process and is not part of an automated nightly or weekly build. It begins when the Release Engineer creates a release branch with all release artifacts. The process finishes after publishing both the artifacts and the related documentation as a release candidate that can be promoted to a final release. |
| ### Version maintenance | ||
| There is no guaranteed support for the bug fixes in the previous Kyma versions. The default strategy is to upgrade to the latest version. | ||
|
|
||
| The Kyma project does not plan to provide any patch releases before the first 1.0 production release and encourages the community to always upgrade to the latest release. |
There was a problem hiding this comment.
first 1.0 release sounds like there's gonna be multiple 1.0 releases. I'd skip "first".
| All Kyma organization members involved in the release process comply with contribution rules defined for Kyma and ensure that all checks built into the continuous integration process pass. These requirements represent the absolute minimal acceptance criteria needed for a release from a compliance perspective. These rules can change as Kyma approaches the 1.0 release. | ||
|
|
||
| Additionally, manual pre-release verification must cover these areas: | ||
| - the use of the third-party software and components that require prior approval |
There was a problem hiding this comment.
"prior approval" refers to an internal process. Maybe rephrase to "licensing"
|
|
||
| Open-source projects, like any other, must ensure secure development. You can provide it by constantly raising the awareness of everyone involved in the project. In Kyma, we strive to make all developers aware of the secure development requirement. For example, we conduct threat modeling workshops during which the participants proactively think about possible security threats in the architecture, infrastructure, and implementation. | ||
|
|
||
| The Release Manager in Kyma takes care of formal security validation activities performed before major releases. The results of these activities influence the release decision. Lack of attention to security topics can result in the release delay. |
Description
Changes proposed in this pull request:
test-infrarepositoryRelated issue(s)
See also #kyma-project/kyma#125