WIP: New release process #219
Conversation
|
@lucacome based on our quick discussion. Before this can be merged we need to discuss what pipeline changes are necessary to fulfill the desired state. |
|
|
||
| - Repeat. | ||
|
|
||
| 1. Once tests have passed create a tag (in the form vMAJOR.MINOR.PATCH) on the main (trunk) commit SHA. The docker image will automatically be pushed to `ghcr.io/nginxinc/nginx-kubernetes-gateway:MAJOR.MINOR.PATCH` with the docker tag reflecting the planned release version. |
There was a problem hiding this comment.
Right now, in the main branch, the YAML manifests and the docs reference the edge tag of the image.
In release branch, the YAML manifests and the docs reference 0.1.0 tag of the image.
That is also documented here https://github.com/nginxinc/nginx-kubernetes-gateway#nginx-kubernetes-gateway-releases - users are advised to make sure the image and the docs and manifests match
If we start releasing from the main branch, for the release tag, we will need to update the docs and manifests to use the release tag of the image and then right after the release we will need to update the docs and manifests to use the edge tag of the image.
There was a problem hiding this comment.
Would it make sense to always have the tags and add a note for edge?
There was a problem hiding this comment.
I think it'll be inconvenient for the user.
|
|
||
| 1. Create a release branch from the planned release tag in main (for example, v0.2.0), use the naming format: release-MAJOR.MINOR. | ||
|
|
||
| 1. Reproduce and fix the bug in main first. This process helps ensure all issues remain fixed in trunk and aren't missed. |
There was a problem hiding this comment.
I think there are two possible scenarios:
- The bug is still present in
main- we fix the bug in the release branch, create a new tag and then merge the branch/tag back tomain. - The bug is not present in
main- we fix the bug in the release branch and create a new tag
There was a problem hiding this comment.
The bug is still present in main - we fix the bug in the release branch, create a new tag and then merge the branch/tag back to main.
what if you get conflicts while trying to merge?
additionally, would it make history non-linear? right now it is linear
|
|
||
| 1. Once tests have passed create a tag (in the form vMAJOR.MINOR.PATCH) on the main (trunk) commit SHA. The docker image will automatically be pushed to `ghcr.io/nginxinc/nginx-kubernetes-gateway:MAJOR.MINOR.PATCH` with the docker tag reflecting the planned release version. | ||
|
|
||
| 1. Update the changelog with the changes added in the release. They can be found in the github release notes that was generated from the release branch. |
There was a problem hiding this comment.
We would also need to create drafts from the main branch
|
|
||
| - Repeat. | ||
|
|
||
| 1. Once tests have passed create a tag (in the form vMAJOR.MINOR.PATCH) on the main (trunk) commit SHA. The docker image will automatically be pushed to `ghcr.io/nginxinc/nginx-kubernetes-gateway:MAJOR.MINOR.PATCH` with the docker tag reflecting the planned release version. |
There was a problem hiding this comment.
Would it make sense to always have the tags and add a note for edge?
|
superseded by #585 |
Change our release process to prefer a lazy branch process.
Describe a planned release and patch release process.
Based loosely on this description: https://trunkbaseddevelopment.com/branch-for-release/
Checklist
Before creating a PR, run through this checklist and mark each as complete.