Semantic release tech talk

Semantic release tech talk

Apiary internal tech talk about Semantic release


Jakub Mikulas

June 10, 2016


  1. Semantic-release

  2. The problems

  3. None
  4. None
  5. None
  6. None
  7. There is a better way

  8. SemVer recap: major.minor.patch

  9. Semantic-release Automated package publishing Takes care of publishing and versioning.

    Helps with keeping changes trackable. Scary docs But in reality, it's pretty simple
  10. It's all about a commit message <type>(<scope>): <subject> feat(scopes): Added

    user:settings:integrations scope
  11. ☞ feat: A new feature ☞ fix: A bug fix

    ☞ docs: Documentation only changes ☞ style: Changes that do not affect the meaning of the code ☞ refactor: A code change that neither fixes a bug nor adds a feature ☞ perf: A code change that improves performance ☞ test: Adding missing tests ☞ chore: Changes to the build process or tools
  12. Yes, you can also define own types

  13. How do they know? Semantic-release will decide on next version

    number according to type of commits you are merging. For example - docs won't even release - bug will do a patch You can note a breaking change (thus forcing major) by adding text BREAKING CHANGE in your commit message You can also do dry-run before pushing.
  14. npm run commit

  15. Getting it to the repo See this PR as a

    reference ➀ Install deps (semantic-release, commitizen, cz- conventional-changelog, condition-circle) ➁ Setup GH_TOKEN and NPM_TOKEN (with CLI tool) ➂ Update package.json (crazy, raqe-inducing part) ➃ Add npm run semantic-release || true to CI deploy step
  16. End notes ☞ Video tutorial on setup: how-to-write-a-javascript-library-automating-releases-with- semantic-release

    ☞ Semantic-release is also fully pluggable ☞ Your versioning should start at 1.0.0 (per npm recommendation)