Add release workflow for this project #215
Conversation
Signed-off-by: Raphael Silva <rapphil@gmail.com>
| To release a new version of the aws-sigv4-proxy, please follow these steps: | ||
|
|
||
| 1. Create a release branch for this minor version series, if one does not exist yet. The convention is to name this branch: `release/v<release series>` where release series has the format `<major version>.<minor version>.x`. Example of branch `release/v1.8.x` | ||
| 2. From the release branch, update the content of the `VERSION` file in the root of this repository. The convention is to ommit the patch version if that is in 0. Example of content: `1.8` or `1.8.1`. Merge the PR that updates the `VERSION` file. Confirm that the continuous integration workflow will succeed. |
There was a problem hiding this comment.
Is this correct? I'd expect the patch component to always be included. It's common to publish image tags that only have the major and minor that always refer to the latest patch version and I would be surprised if 1.8 always pointed to 1.8.0 if 1.8.1 had been released.
There was a problem hiding this comment.
This is just to handle the current state of things. Right now tags and images were created without the patch number.
do you think it is worth changing this pattern moving forward? I don't see any harm in doing that but do you see any risk?
There was a problem hiding this comment.
Consistency is probably more important than aligning with my particular version of correctness here, so definitely keep doing what has been done before for now. I'm not sure whether it's worth making a change moving forward, but if you do communication of the change will be important to avoid surprises.
There was a problem hiding this comment.
Created this issue #216 in case we want to change that in the future.
Issue #, if available: #214
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.