Release process

Pre release tasks

• Merge all pull requests relating to the given release
• Make sure to update all component status labels
  • remove labels from previous minor releases
  • add labels for all new and updated features in current release
  • make sure labels are updated in sidebar, component docs pages, component status page
• Choose the correct version number, following the conventions of semver based on the changes included in the release
  • If the release is only bugfixes, it should be a patch release v.v.X
  • Any added features (new components or new variants/modifiers to existing components) should lead to minor v.X.v version
  • Any big breaking changes should happen in major X.v.v release - there should happen rarely and be carefully planned
• Update version of the framework in relevant places:
  • bump current version in package.json
  • bump version in scss/_settings_system.scss
  • update docs/index.md to add new version to list of latest revisions
• On GitHub releases page update latest draft automatically created by Release Drafter
  • make sure automatic version is correct
  • clean up the log from unnecessary lines, move changes to relevant section if it didn't happen automatically based on labels, reword the changes for better readability

Release

• Pull locally latest version from master
• ./run build
  • make sure everything builds without any errors
• ./run test
  • make sure all test pass

Release on GitHub

• Publish the latest release on Github with the new version number and add the release notes you created earlier.
  • Make sure to mark the release as a pre-release if it's an Alpha or Beta

Release to NPM

• Update your local tags with git fetch --tags
• Check out the tag with git checkout TAGNAME
• Publish the package with npm publish and check that your new release appears on the NPM website

Release to assets server

• ./run build
• upload-assets --url-path vanilla-framework-version-X.X.X.min.css build/css/build.css

Deploy docs.vanillaframework.io

• Deploy to staging (The use the master branch or tag that you created above)
• Make note of the image tag (It will be in the staging deploy output and will be in this format: Image: prod-comms.docker-registry.canonical.com/docs.vanillaframework.io:XXXXXX-XXXXXX
• Test the staging build
• Deploy to production

Deploy vanillaframework.io

• Only deploy the site if the release you have prepared is a full release (i.e., not an alpha or beta build)
• Staging should be automatically deployed when merged.
  • Deploy the site to staging
• Check the staging site
• Deploy to production on http://releases.demo.haus/
  • or Deploy the site to production directly on jenkins

Promotion

• New releases should be announced on newsletter via MailChimp
• New releases should be announced on the @vanillaframewrk twitter account
  • this should happen automatically when newsletter is sent
• Major and minor releases should also be announced in detail on the ubuntu blog