Automated release

[caillou]

Problem / Motivation

8h ago, a feature I was highly anticipating was merged into the master branch. Unfortunately, I will have to wait for someone to manually release this feature, in order to be able to use it without to much hassle.

Solution

Everything that can be automated will be automated.
- Zuboff's 1st Law

If we believe Zuboff, releasing could and therefor will be automated. Ideally using semantic-release. This code runs on a CI server and inspects the commit messages of a merged PR. Following semantic versioning and a convention on commit messages, semantic-release chooses what the next version number is and triggers a releases. Commit messages are used to create the change log.

Did you ever consider automated releasing? Is there any reason we should not use it with next.js?

[nkzawa]

SGTM. Do you know any popular repos doing this which you can refer how it practically works ?

[frederickfogerty]

I think semantic-release is no longer maintained - we were going to use this for react-imgix, but we realised it hadn't been worked on for quite a while

[rauchg]

Related: #293

[kentcdodds]

I think semantic-release is no longer maintained

The latest release of semantic-release was 3 days ago.

I'm a huge fan of semantic-release. It's freed up a lot of my time and enabled me to release more libraries. If you're interested in seeing what the process is like, I've got a (free) course on Egghead.io teaching out to write an open source library where I demonstrate how to use semantic-release.

[kc-dot-io]

@nkzawa We don't fully automate releases on FeathersJS but we do have scripts that are a helpful approach to automating some of the work flow.

The question of how to determine the semantics, is probably the more complex consideration.

[rauchg]

I wonder if an approach similar to Electron auto-updater + nuts + Travis could work, where if you draft a release on GitHub, it gets tagged and published automatically 😱

[rauchg]

That would remove the need for a system that determines the semantics of the changes. The developer(s) do so by drafting a release with the appropriate version number.

[kentcdodds]

The GitHub release draft thing is better than nothing, but the automated versioning and release is really liberating and IMO worth it. Especially with GitHub's squash and merge capabilities (where you can change the commit message as the maintainer) it's quite simple to make sure releases go as you expect/want.

[boneskull]

If someone has found a happy medium between automated releases and manually updating changelogs (and GitHub Releases), I'm all ears. 😄

[kentcdodds]

You could reasonably update the auto-generated GitHub release page with semantic-release and/or you could maintain your own CHANGELOG.md

[boneskull]

@kentcdodds I think that workflow might want to create a draft release with an auto-generated changelog which I can edit. Upon publishing, it should update CHANGELOG.md. The updates to CHANGELOG.md should be before the release changeset is created & tagged (or along with it), ideally

[boneskull]

(the "publish" action would not happen on GitHub though)

[kentcdodds]

Interesting... I'm unaware of any tool to automate that process...

[boneskull]

The reasoning here is that currently I'm copying & pasting from CHANGELOG.md into my GitHub release. Greenkeeper will include the release notes when sending PRs.