Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add release-drafter config #361
Add release-drafter config #361
Changes from 1 commit
60914e5
28741f8
0f97e42
0a79e69
b064cad
5f62383
7db7668
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be
breaking
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
breaking
does not deserve a label, and luckily we do not have one. Most changes marked as major are breaking but not all breaking labels are major. Sometimes major covers other changes.We need to be careful to keep labels under control as I seen projects with tickets becoming like xmas tree and confusing users, most not even knowing what to pick. This list is short but enough in order to put changes in the right bucket (section). We can revise if needed but first let it settle so we get used to adding the right labels to the tickets.
BTW, My favorite feature is the release-drafter is that you can add the label or fix the PR title after the merge and at the next run, it will correct the draft. Still once a release is made, the bot will not touch the text, only humans can edit it.
There is also the aspect of "breaking" having negative connotations, something we may want to avoid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair points.
Can you address my larger question about it isn't better to use Semantic Release and get all this PLUS automatic release? @ssbarnea
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I never used Semantic Release, two things come into my mind:
Altering commit message does retrigger the whole testing pipelines. That is why I prefer the idea of dealing with release notes on a OOB channel, as it is mostly bureaucracy, needed but it should not block or slowdown the PRs.
Please note that I did not propose to ditch current changelog (or the guidelines for changes). So mainly what we do now is to experiment how good is this approach for our project. I do expect to copy/paste the release notes and merge them to the changelog before each release, at least until we are confident that it works fine. I do not want to confuse existing users with something the cores are only exploring.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm inclined to agree with the two points @ssbarnea brings up above ( especially point 2 ). We could always move to semantic release if we find this too tedious
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it still is. Based on the the tag used in the commit message a release (major/minor/patch) will happen - or not.
What's the point in hoarding? If we merged a new feature, an update or a bugfix, why not release that right away?
We don't have to use commit messages as release notes. That's configurable. The commit messages only drive if a release happens and what type. What's being merged is controlled by a select few of us. If you feel wrong things are being merged we need to have a discussion about that and actions need to be taken to stop or at least minimize the risk.
Furthermore there are tools to make sure that commit messages follow a set pattern.
We use Semantic Release in a professional setting across many different repos. If it's good enough for that, it's good enough for OS.
However, with that said, one potential negative aspect is if there are too many hoops to jump through to contribute to the project, we may scare away new contributors.
But, like @gnikonorov said, nothing stopping us from trying out SR later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is gold "one potential negative aspect is if there are too many hoops to jump through to contribute to the project, we may scare away new contributors." -- I seen in in the past, where maintainers succeeded in adding enough bureaucracy to deter most users. I am really glad we are aware of the risks.
This area is more of a tuning game, as long we adapt fast and learn from our mistakes we should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I question if we really need all three of these? I would say
fix
would suffice.