Add Release Drafter

[asbjornu]

Subject of the feature

With Release Drafter, creating GitHub releases becomes mostly automatic.

Problem

It requires quite a bit of manual labour to create release notes. Release Drafter automates most of this labour, making the creation of new releases much easier.

Expected behavior

The creation of releases should not be a tiresome, manual ordeal.

Alternatives

GitReleaseManager is an option, but it's more heavy-handed than Release Drafter. There exists a lot of other alternatives as well, but I have not familiarized myself with them.

[wooorm]

No strong opinions here, but I’m a fan of manually releasing + writing release notes 🤷‍♂️

[asbjornu]

I agree the release publishing should be manual, but the labour of adding issue numbers, author names, titles, etc., to a draft release is something that could and should be automated, imho.

[wooorm]

the labour of adding issue numbers, author names, titles, etc.

I add issue, pr, and commit references, plus author / reviewer names, etc, to commits. Example: wooorm/xdm@f9c3108.
Because I squash, that leaves the commit log as essentially a changelog: I edit a little bit: remove a couple things, add some more where needed. And done! That labor has to be done somewhere, and this is pretty and useful: https://github.com/nodejs/node/commits/master

[asbjornu]

Yes, conventional commits are nice when enforced. I just don't have the time nor energy to enforce them and thus Release Drafter is an easy way out.

[ChristianMurphy]

I just don't have the time nor energy to enforce them and thus Release Drafter is an easy way out.

That's what CommitLint is for 🙂 (https://commitlint.js.org)

An example integration with GitHub action: https://github.com/uPortal-Project/uPortal-web-components/blob/1dfd1788a9f935e274b026e69ad95266bbcf24b2/.github/workflows/CI.yml#L39-L40

[asbjornu]

Sorry, the last comment was posted in error. I'll have a look @ChristianMurphy.

[asbjornu]

With #50 merged, I thought this would be a good time to create a new release and with all the merges now being squashed, the job of creating the release notes has become even more tiresome, as the Git log no longer contains the merge messages with the PR number.

I don't want the release notes to only enumerate what's new, I want a reference to the PR that implemented the change and who implemented it.

Release Drafter automates all of this. Even with CommitLint set up, the work of creating the release notes needs help from a tool. I'm not going to be manually finding the source PR of each commit on the main branch.

I hope you have suggestions for how to deal with this, because the current situation makes me not want to create any releases.

[wooorm]

@asbjorn I think it's ok if you don't want to cut releases. Let me know when you want me to do so, and how I can do that with your current set up of the repo

[asbjornu]

It's not that I don't want to cut releases period, I just don't have the time to cut them as things are now without any help from tooling such as Release Drafter. If you can agree to give it a try, I'll happily create releases going forward.

[remcohaszing]

I suggest to the following release process:

• Keep manual GitHub releases as most of the unified ecosystem.
• Use a GitHub action to release to both Open VSX and the VS Code Marketplace, which aligns with ci: add publish workflow for releasing on CI automatically mdx-js/mdx-analyzer#207.

[JounQin]

The GitHub release is auto created on tag pushed by Changesets Action

https://github.com/mdx-js/vscode-mdx/blob/master/.github/workflows/release.yml

https://github.com/mdx-js/vscode-mdx/blob/master/.github/workflows/version.yml

We only need to focus on changesets.

[asbjornu]

The difficult and boring task is to create the changelog that goes into the releases, not creating the release itself. Release Drafter can be used to automatically aggregate all pull requests that are merged into a changelog, so the changelog doesn't have to be punched in manually.

[JounQin]

The difficult and boring task is to create the changelog

changesets changelog can be added with help its not comment or cli, and the content is always editable before release, instead of depends on commit message only.

PR related links like author and original author are referenced automatically instead.

Changesets is a great tool to me personally, although adding changeset needs some verbose action, but it's very scalable.

[asbjornu]

The content Release Drafter creates is also editable. What it does is that whenever a pull request is merged, if a drafted release does not exists, it is created. The release is created in draft state so it is not published or available publicly. While pull requests are being merged, the draft release is updated with new content, adding to the changelog. All automatically. Once the release is ready to go, someone goes through it and sees that it looks good, gives it a proper version number and turns it from "draft" to "published" state, making it public and available to the world.

Release Drafter only needs one configuration file and doesn't need anything to be done in every pull request to indicate that "this should go into the release". It's much easier to just have every pull request added automatically and then delete stuff that shouldn't be there right before publishing the release. Release Drafter is a great tool and I don't understand the resistance to use it while at the same time embracing changesets, which seems like a much heavier and more complex solution to me.

[JounQin]

Release Drafter is a great too

Seems it's also sweet, I'll give it a try in my projects later, thanks for points.

[wooorm]

Closing, agreeing with Remco above.
I quite disagree that writing changelog entries are difficult and boring. I am rather proficient at creating them from Git history, and do not find the work tedious.

---

I'm not going to be manually finding the source PR of each commit on the main branch.

GH does that. And our commit messages include that info.

It's much easier to just have every pull request added automatically and then delete stuff that shouldn't be there right before publishing the release.

Using commit history also allows for this.

[asbjornu]

Ok, you do releases then. I’m out.