Summary
Versioning keeps the Opries style guide accountable as the brand and product system evolve. Changes should explain their use case, accessibility impact, and relationship to public brand or platform UI guidance.
Versioning
Use semantic versions for published guide releases.
| Version | Meaning |
|---|---|
| Major | Significant brand, token, or component direction changes |
| Minor | New sections, patterns, examples, or non-breaking token additions |
| Patch | Corrections, wording improvements, or small clarifications |
Contribution Rules
Every change should identify whether it affects the public brand, platform UI system, or both. Token changes must include the reason, affected components, and accessibility notes.
Design and content changes must also state:
- The primary use case and audience.
- Any Universal Design considerations.
- Any Universal Design for Learning considerations if the change educates the public or users.
- How the change supports Swiss/International design principles or why another approach is more suitable.
Review Process
- Draft change in a branch.
- Check content and build the site.
- Review for brand clarity, platform usefulness, accessibility, Universal Design, learning support, and visual-system discipline.
- Update
CHANGELOG.md. - Merge to
mainfor Cloudflare Pages publication.
Release Notes
Release notes should summarise what changed, who the change affects, and whether product teams need to update code, design files, or content templates.
Checks
- Does the change state whether it affects public brand, platform UI, or both?
- Are accessibility and Universal Design considerations recorded?
- Does the changelog explain the reason for the change?
- Has the content check and static build been run before publishing?