Semantic Release

[colinrymer]

It'd be awesome to have a new version automatically released when a PR is merged.

We've been using semantic-release along with commitizen on our open source JS projects to have Travis CI automatically publish a new appropriately-incremented version to NPM and create a GitHub release with a changelog when we merge a PR into master.

I bring this up because #437 was just merged, but we need to wait until a new version is released before we can use it. I was going to open a PR to bump the version, but I'm not sure what version number should be bumped to.

I'd love to help set this up if this is something you all are interested in, and I'm happy to answer any questions you might have about semantic-release/commitizen.

[honzajavorek]

@colinrymer Wow, thanks very much for the suggestion! I'll check it out at least briefly first and let you know :+1:

[honzajavorek]

I scanned through semantic-release and commitizen. While I see it can be useful for some projects, I feel like it's a lot of added automation and special convention and, frankly, I'm a bit satisfied with the fact that I'm doing releases manually. While I'm fan of continuous delivery, I like that I'm the one who does the final decision what gets released with what and when. I feel it still has some benefits, because there are many edge cases to be handled:

• Sometimes there are multiple PRs needed to deliver a complete feature, so releasing a new version right away isn't something I would want.
• Sometimes tests pass even if the code is wrong, because there is a bug in them.
• npm defaults to "package": "^version", so small changes propagate very fast through the ecosystem. At the same time, it's very easy to overlook a mistake in PR review or introduce regressions with a single PR.
• Dredd is a CLI app rather than library, so I need to care also about what gets installed when people just type npm install -g dredd.
• We do some extensive integration testing with all hook handlers when new Dredd version is about to be released.

This all makes me pretty defensive in what I allow to be released. It's possible that all these cases can be handled also with the automatic system, but my perception is that it would need me to set it all up, maintain some set of rules and exceptions, take care about format of my commits and commits of contributors, etc. Currently, all I need to do is to

• spend 3 minutes evaluating, thinking, planning
• spend 5 minutes releasing and editing the Changelog to be more reader-friendly (add headings)

I see the benefits fast releasing brings to contributors - merged stuff goes live quickly. OTOH, it feels to me like it's on-the-edge vs. pretty-stable tradeoff. I lean more to pretty-stable & well-tested before I release stuff.

However, since the issue got quite some support :+1: in GitHub reactions, I'll try to be more fast in releasing patch versions. I agree your contribution could have been released right away. I will prepare some degree of release automation to make it easier for me to spawn a new version and I'll try to do it more often in cases like yours.

[colinrymer]

Thanks for the investigation and thoughtful reply. Totally understand! 👍

[honzajavorek]

This issue initiated internal discussion in Apiary. Some other teams liked the idea more than me and started to adopt it on several smaller projects. After some time and positive testimonials from these early adopters, we as a company decided to standardize our commit messages to use the conventional changelog format.

I tried Semantic Releasing on dredd-transactions and it seems to be really very helpful and takes away a lot of maintainer's overhead. (It turned out to be so addictive I now hate to contribute to projects which do not use it!) It seems to bring great benefits especially to smaller projects which don't have my constant attention, such as gavel.js or gavel2html and I'm planning to put Semantic Releasing also on those, ASAP.

In mid-term, I'd like to also get Dredd closer to Semantic Releasing. That's why I

• made integration tests for hooks more friendly in https://github.com/apiaryio/dredd/pull/579
• and closed https://github.com/apiaryio/dredd/issues/440 right now in favor of re-opening this.

@colinrymer Thank you again for bringing this issue up! I'll try to report here later about progress or to mention possible blockers.

[honzajavorek]

Anyone knows how does it work with npm dist-tags and pre-releases? Currently, we have #497 in place:

• All versions get dist-tagged as latest and stable by default.
• If we're in the process of developing a new feature, we publish pre-releases, which get tagged only as latest.

People putting Dredd to CIs are encouraged to use npm i dredd@stable there. My notes on how semantic release works with dist-tags:

If you want to use another dist-tag for your publishes than 'latest' you can specify that inside the package.json’s publishConfig field. -- README

• publishConfig
• config.tag

Currently I'm not sure how to make the process automated.

[honzajavorek]

One approach would be:

• use sem rel and see if any pre-releases are still needed
• publish every version with both tags
• if there's real need for pre-releases and stable in the future, then
  • make an integration branch for the feature, change tag in publishConfig, configure sem rel to release also from that branch and to make just pre-releases from that branch
  • make feature branches out of that branch and let sem rel publish pre-releases when something gets merged
  • (what would happen if I'd like to get commits from master to this branch?)
  • once the feature is ready, remove the extra setting for sem rel and merge the integration branch to master (what would be resulting version bump on master then?)