Release process

Deploy vanilla framework

• Merge all pull requests relating to the particular release milestone
• 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

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)
• Deploy the site to staging
• Check the staging site
• Deploy the site to production

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

Promotion

• New releases should be announced on the @vanillaframewrk twitter account
• Major and minor releases should also be announced in detail on the ubuntu blog