Closed caillou closed 6 years ago
SGTM. Do you know any popular repos doing this which you can refer how it practically works ?
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
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
.
@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.
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 😱
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.
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.
If someone has found a happy medium between automated releases and manually updating changelogs (and GitHub Releases), I'm all ears. :smile:
You could reasonably update the auto-generated GitHub release page with semantic-release and/or you could maintain your own CHANGELOG.md
@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
(the "publish" action would not happen on GitHub though)
Interesting... I'm unaware of any tool to automate that process...
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.
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".
@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.
@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
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.
@kentcdodds I would love to use an existing solution :) My only requirements for our organization are:
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.
If someone extends an existing solution to do this, or can point us in the direction of one, I'd be very grateful
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
@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!
@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 😄 👍
@leo has implemented automatic releasing of new versions in github.com/zeit/now-cli with circle CI.
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.
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
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
?