Skip to content

Release process

Bartek Szopka edited this page Dec 6, 2019 · 26 revisions

Deploy vanilla framework

  • Merge all pull requests relating to the particular release milestone
  • 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
  • Update app-version to the new version number in scss/_settings_system.scss, package.json and docs/index.md
  • Collate commit logs from last release and use them to prepare release notes - copying the format for previous releases
  • Run ./run test and ensure no errors or warnings appear
  • Create a Github release with the new version number and add the release notes you created earlier. Note: mark the release as a pre-release if it's an Alpha or Beta
  • 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

Upload to assets server

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

Deploy vanillaframework.io/docs

NOTE Vanilla docs currently use the NPM build of Vanilla and, therefore, can be out-of-sync with the framework. A workaround is to bump the version on vanilla-framework in package.json and then releasing the docs site from master rather than the tag.

  • Deploy to staging (The use the 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

Promotion

Clone this wiki locally