This document describes the release processes and conventions for the Gov.AU Guides UI Kit.
Versioning will be done using Semantic Versioning and will using the following additional rules for version incrementation:
- Patch: Bug-fixes or small visual changes (margins, colours etc)
- Minor: release includes new features that does NOT affect existing markup or code (new features that provide additional markup can be included here)
- Major: Release includes features that require existing markup must to be changed to satisfy SASS or JS changes in the release
Each MAJOR release will come with a code name to ease communication.
Major Release | Codename | Description |
---|---|---|
0.x.x | Rugby | Pre-release for GovAU projects and for preliminary feedback amongst the Australian Public Service (APS) |
1.x.x | Kraken | Stable release target for APS Distribution |
2.x.x | Boomerang | TBD |
Two separate deployed versions of the UI Kit will be maintained.
Branch | Server | URL |
---|---|---|
develop | Staging | design-guide.apps.staging.digital.gov.au |
master | Production | guides.service.gov.au/design-guide |
Production will always host the latest release and will be considered stable. Staging will host the current code at the develop branch and may not necessarily be stable.
Release and other announcements will be made via UI Kit Announce
Releases will be made using git-flow
Before commencing the release choose a version based on the criteria described above.
Using git-flow create a release branch:
git flow release start x.x.x # Use the actual release version
Make sure that wherever the version is stored or set in the code, the version now matches the version for this release.
Files impacted:
package.json
, line 3assets/sass/ui-kit.scss
, line 3CHANGELOG.md
Describe the version and list changes that we made (review the sprint in Jira if required).
Commit any version bump or other last minute changes.
git commit -am "Bumped version to 0.1.4"
git flow release finish x.x.x # Use the actual release version
Ensure that you are now in the master branch and do:
git push origin master
git push --tags
Open the release in your browser via UI Kit releases. Click the Tags tab, locate the latest release and click "Add release notes" for that tag.
Enter detailed release notes based on the changelog. In particular, the following should be covered where appropriate:
- Upgrading from older releases (are markup changes required)
- Details of any visual changes
- Details of syntax or semantic changes
- Bug fixes
- New capabilities
Ensure that the master branch has been deployed to the production server and that the current version is displayed somewhere on the page.
Send an email to the UI Kit Announce Google Group.
The email should contain the release information (copy paste from Github is fine) and where developers can access or download the latest code.
Changelogs will be kept in CHANGELOG.md and updated where appropriate. Generally, a changelog entry should form part of the acceptance criteria for a ticket.