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

Add release-drafter config #361

Merged
merged 7 commits into from
Nov 11, 2020
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
Add release-drafter config
ssbarnea committed Oct 24, 2020
commit 60914e5eb15320f0d14d39fac5934d88ae0babd3
26 changes: 26 additions & 0 deletions .github/release-drafter.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
categories:
ssbarnea marked this conversation as resolved.
Show resolved Hide resolved
- title: 'Major Changes'
labels:
- 'major' # c6476b
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

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:

  • Decision to release should be left to humans, we do not want too many releases, and we didn't even add AI ;)
  • Reading https://github.com/semantic-release/semantic-release#commit-message-format -- i do not think that commit messages are safe to use for release notes, main reason is that once merged you cannot change it. It is too easy to merge wrong stuff. That is why almost everyone is using an other ways of dealing with release notes either using fragments, static changelog or fully outside git.

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.

Copy link
Member

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

Copy link
Contributor

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:

  • Decision to release should be left to humans, we do not want too many releases, and we didn't even add AI ;)

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.

Copy link
Member Author

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.

- title: 'Minor Changes'
labels:
- 'feature' # 006b75
- 'enhancement' # ededed
- 'performance' # 555555
- title: 'Bugfixes'
labels:
- 'fix'
- 'bugfix'
ssbarnea marked this conversation as resolved.
Show resolved Hide resolved
- 'bug' # fbca04
Comment on lines +13 to +15
Copy link
Contributor

@BeyondEvil BeyondEvil Nov 10, 2020

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.

- 'docs' # 4071a5
ssbarnea marked this conversation as resolved.
Show resolved Hide resolved
- 'packaging' # 4071a5
- 'test' # #0e8a16
ssbarnea marked this conversation as resolved.
Show resolved Hide resolved
- title: 'Deprecations'
labels:
- 'deprecated' # fef2c0
exclude-labels:
- 'skip-changelog'
template: |
## Changes

$CHANGES
18 changes: 18 additions & 0 deletions .github/workflows/release-drafter.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
name: Release Drafter

on:
push:
# branches to consider in the event; optional, defaults to all
branches:
- master
- 'releases/**'
ssbarnea marked this conversation as resolved.
Show resolved Hide resolved
- 'stable/**'

jobs:
update_release_draft:
runs-on: ubuntu-latest
steps:
# Drafts your next Release notes as Pull Requests are merged into "master"
- uses: release-drafter/release-drafter@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}