Skip to content

Automation Processes Versioning and Publishing

Jenna Badanowski edited this page Apr 16, 2020 · 3 revisions

Semantic Versioning and Why we use it

  • Major.Minor.Patch
  • e.g. 1.11.2
  • Why: makes our actions clear to customers
  1. Major:
    • Breaking change
    • Backwards incompatible: changes will not work with previous versions
    • Minor and patch versions will be reset to 0 on major change
    • e.g. change markup for a component
  2. Minor:
    • Feature
    • Backwards compatible: changes will still work with previous versions
    • Patch version is reset to 0 when minor version is incremented.
    • e.g. adding a new component
    • Pull request prefix: feat:
  3. Patch
    • Bug fixes
      • Internal change that corrects incorrect behavior
      • e.g. fix the focus on an input box
      • Pull request prefix: fix:
    • Chore
      • e.g. update dependency
        • Pull request prefix: chore:
    • Docs
      • e.g. change to the documentation
      • Pull request prefix: docs:

      NOTE: if the change involves any changes in the html of a component, this is no longer a documentation change and is now a BREAKING CHANGE

What is RC

  • release candidate
  • Can plan on it working well - it is code that will be released unless there is a last minute bug found. Broken code or "work in progress" code should not be merged as a "rc".

Zeroth version library

  • Initial development
  • Anything can change at any time without having to worry about stacking breaking changes in a major release.
  • MAJOR.MINOR.PATCH moves down one level:
    • MAJOR: this stays at 0 until we decided to go to 1
    • MINOR:
      • Breaking change
      • Backwards incompatible: changes will not work with previous versions - a consumer will have to make changes in their project to use this new version.
      • e.g. change markup for a component
      • Pull request prefix: feat:
    • PATCH:
      • Backwards compatible: changes will work with previous versions
      • Features that do not involve breaking changes: new components, new component features, etc.
      • Bug fixes: Internal change that corrects incorrect behavior e.g. fix the focus on an input box
      • Chore: e.g. update dependency, documentation changes, script edits
      • Pull request prefix: chore:, fix:, docs:

Creating a pull request to work with versioning

  • Why:
    • Communicates our changes clearly
    • Automatically updates our CHANGELOGs
  • Make sure the title of your pull requests includes a prefix followed by a one-line summary of change:
    • Non-zeroith library:
      • Major: BREAKING CHANGE: deleted existing type prop from button component
      • Minor: feat: created inline help component
      • Patch: fix: edited broken link for tile background image
    • Non-zeroith library:
      • Major: Do not use
      • Minor: feat: deleted existing type prop from button component
      • Patch: fix: edited broken link for tile background image - fix: new component - chore: update dependency - docs: update documentation site logo

When you want to run a release:

  • Contact team on github to make sure everyone is okay with a new release
  • npm run release

Travis Builds - Three Scenarios:

You’ve created a pull request:

  1. PR triggers travis.yml
    • runs lint and test stage, no other qualifications are met, stops here.

You’ve merged a PR to master:

  1. Merge triggers travis.yml
    • Run lint and test stage
    • Branch = master, so runs pre-release stage
  2. Triggers ci-scripts/setup-npm.sh
  3. Triggers ci-scripts/publish-rc.sh - Runs standard version -package, package-lock, changelog - Pushes standard version changes back to GitHub (master) - npm publish: Publishes lib folder to npm

You want to release a non-rc version, so you’ve run npm run release:

  1. npm run release -> scripts/publish-release.sh:
    • creates, pushes + deletes (locally) tmp_branch_for_automated_release_do_not_use in order to trigger travis
  2. travis.yml
    1. Triggers ci-scripts/setup-npm.sh
    2. Triggers ci-scripts/publish.sh
      • Deletes (remotely) tmp_branch_for_automated_release_do_not_use
      • Runs standard version - package, package-lock, changelog
      • Pushes standard version changes back to GitHub (master)
      • npm publish: Publishes lib folder to npm
      • npm run release:create: uses GitHub-assistant to create release notes
      • npm run build-doc: build documentation site in build folder
      • npm run deploy: send build folder to GitHub pages

How you can check your travis builds

  • travis-ci.org/travis-ci.com