Set up release-drafter #202
Conversation
|
This will changes the versioning scheme to |
| categories: | ||
| - title: '💥 Breaking Changes' | ||
| labels: | ||
| - 'changelog:breaking' # When a breaking change is introduced | ||
| - title: '✨ Features' | ||
| labels: | ||
| - 'changelog:feature' # When a new feature is introduced | ||
| - 'changelog:enhancement' # When an existing feature is improved | ||
| - title: '🐛 Bug Fixes' | ||
| labels: | ||
| - 'changelog:fix' # When a bug is fixed | ||
| - title: '📝 Documentation' | ||
| labels: | ||
| - 'changelog:docs' # When documentation is updated | ||
| - title: '🧰 Maintenance' | ||
| labels: | ||
| - 'changelog:chore' # When a chore is done | ||
| - 'changelog:ci' # When CI is updated | ||
| - 'changelog:dependencies' # When dependencies are updated | ||
| exclude-labels: | ||
| - 'changelog:skip' # When a PR should be excluded from the changelog |
There was a problem hiding this comment.
We can still discuss the appropriate labels.
There was a problem hiding this comment.
ahh ignore previous comments, can we remove the changelog: prefix from these? Except for the changelog:skip label.
|
Existing example: https://github.com/elastic/oblt-actions/releases |
Mpdreamz
left a comment
Mpdreamz
left a comment
There was a problem hiding this comment.
Some nits otherwise lgtm, can't wait to add this!
| categories: | ||
| - title: '💥 Breaking Changes' | ||
| labels: | ||
| - 'changelog:breaking' # When a breaking change is introduced | ||
| - title: '✨ Features' | ||
| labels: | ||
| - 'changelog:feature' # When a new feature is introduced | ||
| - 'changelog:enhancement' # When an existing feature is improved | ||
| - title: '🐛 Bug Fixes' | ||
| labels: | ||
| - 'changelog:fix' # When a bug is fixed | ||
| - title: '📝 Documentation' | ||
| labels: | ||
| - 'changelog:docs' # When documentation is updated | ||
| - title: '🧰 Maintenance' | ||
| labels: | ||
| - 'changelog:chore' # When a chore is done | ||
| - 'changelog:ci' # When CI is updated | ||
| - 'changelog:dependencies' # When dependencies are updated | ||
| exclude-labels: | ||
| - 'changelog:skip' # When a PR should be excluded from the changelog |
There was a problem hiding this comment.
ahh ignore previous comments, can we remove the changelog: prefix from these? Except for the changelog:skip label.
README.md
Outdated
| > [!NOTE] | ||
| > When a release is published, the [create-major-tag workflow](../.github/workflows/create-major-tag.yml) | ||
| > will force push a new major tag in the format `vX` where `X` is the major version of the release. | ||
| > For example, if the release is `v1.2.3` was published, the workflow will force push a new tag `v1` on the same commit. |
There was a problem hiding this comment.
Can we drop the v* prefix from the release-drafter? Just because we are already set up with Major.Minor.Patch tags.
Alternatively I can update our minver and workflow triggers.
There was a problem hiding this comment.
I expected this discussion.
We can use a version with the v prefix.
Would you also like to remove the automation for v1,v2, etc tags? Or do we actually also create this?
this is mainly for the github actions usage convention
There was a problem hiding this comment.
Thanks! yeah release tags being \d.\d.\d and special v\d tags for github actions works for me!
Mpdreamz
left a comment
Mpdreamz
left a comment
There was a problem hiding this comment.
Some nits otherwise lgtm, can't wait to add this!
The following information was also added to the README.md
Release Process
This section outlines the process for releasing a new version of this project.
Versioning
This project uses Semantic Versioning and its version is automatically determined by release-drafter based on the labels of the pull requests merged into the
mainbranch.See the release-drafter configuration for more details.
Creating a New Release
Every time a pull request is merged into the
mainbranch, release-drafter willcreate a draft release or update the existing draft release in the Releases page.
To create a new release you need to publish the existing draft release created by release-drafter.
Important
Make sure the release-drafter workflow is finished before publishing the release.
Note
When a release is published, the create-major-tag workflow
will force push a new major tag in the format
vXwhereXis the major version of the release.For example, if the release is
v1.2.3was published, the workflow will force push a new tagv1on the same commit.