Skip to content

Add release-drafter config #361

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.

Sign up for GitHub

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

Merged
merged 7 commits into from
Nov 11, 2020
Merged

Add release-drafter config #361

Show file tree
Hide file tree
Changes from 5 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
60914e5
Add release-drafter config
ssbarnea Oct 24, 2020
28741f8
Merge branch 'master' into gh/release-drafter
ssbarnea Oct 25, 2020
0f97e42
Merge branch 'master' into gh/release-drafter
ssbarnea Nov 4, 2020
0a79e69
Merge branch 'master' into gh/release-drafter
ssbarnea Nov 8, 2020
b064cad
Update release-drafter.yml
ssbarnea Nov 9, 2020
5f62383
Update release-drafter.yml
ssbarnea Nov 10, 2020
7db7668
Merge branch 'master' into gh/release-drafter
ssbarnea Nov 10, 2020
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
26 changes: 26 additions & 0 deletions .github/release-drafter.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
categories:
- 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
- 'docs' # 4071a5
- title: 'Bugfixes'
labels:
- 'fix'
- 'bugfix'
- 'bug' # fbca04
Comment on lines +13 to +15
Copy link
Contributor

@BeyondEvil BeyondEvil Nov 10, 2020 •
edited
Loading

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.

- 'packaging' # 4071a5
- 'test' # #0e8a16
- title: 'Deprecations'
labels:
- 'deprecated' # fef2c0
exclude-labels:
- 'skip-changelog'
template: |
## Changes

$CHANGES
18 changes: 18 additions & 0 deletions .github/workflows/release-drafter.yml
View file
Open in desktop
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/**'
- '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 }}