Closed ungoldman closed 1 year ago
npm i -g semantic-release && cd cool-project && semantic-release-cli setup
is working wonders for me.
If you forget to write conventional commit messages, you can rewrite a semantic message with a squash or merge commit message.
Yeah let’s try it
@zeke my main gripe with semantic-release
is that it doesn't update the version in package.json
. I understand their reasoning, I just disagree with it.
Just read that. Weird, they don’t really justify why they don’t update it, only about why it happens to work.
Sent from my mobile
On Dec 23, 2017, at 12:10 PM, Nate Goldman notifications@github.com wrote:
@zeke my main gripe with semantic-release is that it doesn't update the version in package.json. I understand their reasoning, I just disagree with it.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I think the idea is that as soon as your code changes, the value of version
in package.json is no longer reflective of reality. I found this a little odd at first too, but just decided to let go and haven't looked back.
If you end up using standard-version
, please share your thoughts on it!
Oh I guess that makes sense.
Sent from my mobile
On Dec 28, 2017, at 10:38 AM, Zeke Sikelianos notifications@github.com wrote:
I think the idea is that as soon as your code changes, the value of version in package.json is no longer reflective of reality. I found this a little odd at first too, but just decided to let go and haven't looked back.
If you end up using standard-version, please share your thoughts on it!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Memories...
RIP 🫡
Managing releases is a bit laborious -- one thing we could automate is change logs and version numbers.
I've tried out a couple different solutions and have found standard-version to be the best so far.
One caveat is that it requires writing commits in a very specific way ("conventional commits"). See https://conventionalcommits.org/ for more info on that.
The advantage is if you write your commits in this format, a readable, well-formatted change log can be automatically generated, and appropriate version bumping with semver can be be inferred from the commits themselves (fixes, features, breaking changes).
Let me know if you're willing to try it out @bcomnes.