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.

[MoOx]

If that can help someone i made this a while ago (but still using it). It reads CHANGELOG section that match your package.json version and update a git tag on github, which create a "github release".

https://github.com/MoOx/github-release-from-changelog

[rauchg]

@boneskull

I think drafts is where it is. For example, you can have a tool populate a draft changelog automatically. But then the dev always has the last say to make exceptions. Since we're dealing with such a highly dynamic system, it's impossible to expect the process to be fully automated.

[bcoe]

@boneskull I've been using standard-version for all my OSS projects, it's specifically designed to help with the CHANGELOG generation, semantic bumping, and tagging process, without explicitly performing the final step of publishing:

https://github.com/conventional-changelog/standard-version

although, I have been experimenting with this a bit in the yargs-parser project, using Travis' release tools:

https://github.com/yargs/yargs-parser/blob/master/.travis.yml

[kentcdodds]

I'll just say that I'm hopefully that Zeit doesn't roll its own thing. I would rather we contribute to something that already exists and is 95% what is needed and just make it better.

[rauchg]

@kentcdodds I would love to use an existing solution :) My only requirements for our organization are:

• Any commit style should work, therefore:
• It should allow the developer to determine the version
• I'm biased towards the nuts+electron-auto-updater workflow with drafts. After the draft is published, we kick in the npm publish job.

Drafts on github are reviewable and collaborative, which is the missing piece of the puzzle. This effectively makes "npm publish" a peer-reviewed and automatic process.

[rauchg]

If someone extends an existing solution to do this, or can point us in the direction of one, I'd be very grateful

[timneutkens]

Zeit introduced release which does most of the above. The only thing we'd have to do is kick in a npm publish job after a draft is published https://github.com/zeit/release

[shilman]

@timneutkens @rauchg @arunoda Love the format of your release notes,
e.g. 2.4.0! Is this at all automated?

Trying to do the same thing for Storybook's upcoming 3.0 release.

Your "release" tool mentioned above looks awesome, but as far as I can tell it looks at commits not PRs, and we want to curate at the PR level.

Any thoughts/help much appreciated! Many thanks!

[timneutkens]

@shilman the split has been done manually. But based off of release's commits. The way this works is that we squash-merge a pull request instead of merging it. Which leaves only one commit in master which mentions the pull request 😄 👍

[timneutkens]

@leo has implemented automatic releasing of new versions in github.com/zeit/now-cli with circle CI.

[lock]

This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.