Skip to content
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.

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

docs(*) update the release process description #975

Merged
merged 2 commits into from
Sep 14, 2020

Conversation

nickolaev
Copy link
Contributor

Signed-off-by: Nikolay Nikolaev nikolay.nikolaev@konghq.com

@nickolaev nickolaev requested a review from a team as a code owner August 13, 2020 14:39

### Patch releases

After the initial release there may be a need for a patch release `A.B.1`, `A.B.2` and so on. These typically include only fixes to critical issues, but there might be exceptions where features are backported from master. I most cases the patch releases follow a lighter weight release procedure, without `rc` versions and a testing/verification cycle focused on the chanaged/fixed functionalities.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If patch contains only critical fixes we will be incrementing minor version much faster. I'm ok, but I just wanted to point this out so we are on the same page.

The process to release a Kuma version is as follows:
* Create the release branch `release-A.B` and tag `A.B.0-rc1`
* Next 2 days, test the `rc1` version for the backward compatibility, breaking changes and upgrade instruction. Verify the newly added feature are working as expected. Check the documentation reflects the breaking changes and the new functionality.
* If a critical problem is found, fix it and release `rc2`. Run the test/verification procedures again
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which means no last-minute changes 👍


The process to release a Kuma version is as follows:
* Create the release branch `release-A.B` and tag `A.B.0-rc1`
* Next 2 days, test the `rc1` version for the backward compatibility, breaking changes and upgrade instruction. Verify the newly added feature are working as expected. Check the documentation reflects the breaking changes and the new functionality.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be great if one of those days would be Friday, so if we introduce Test Fridays, the person testing the product could do this for RC

RELEASE.md Outdated
### Releases

The process to release a Kuma version is as follows:
* Create the release branch `release-A.B` and tag `A.B.0-rc1`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and include GUI into it. Until now, GUI was compiled into the product as a last step before release

@nickolaev nickolaev merged commit 275975e into master Sep 14, 2020
@nickolaev nickolaev deleted the docs/release_process branch September 17, 2020 05:45
nickolaev pushed a commit that referenced this pull request Oct 1, 2020
Signed-off-by: Nikolay Nikolaev <nikolay.nikolaev@konghq.com>
nickolaev pushed a commit that referenced this pull request Oct 1, 2020
Signed-off-by: Nikolay Nikolaev <nikolay.nikolaev@konghq.com>
nickolaev pushed a commit that referenced this pull request Oct 5, 2020
Signed-off-by: Nikolay Nikolaev <nikolay.nikolaev@konghq.com>
nickolaev pushed a commit that referenced this pull request Oct 5, 2020
Signed-off-by: Nikolay Nikolaev <nikolay.nikolaev@konghq.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants