Olympus Docs
CookbookUI & content

Release notes for auth changes

How to communicate changes that affect users

When you ship auth changes (new MFA, password policy, login UX), users need to know. Done well, builds trust. Done poorly, support floods.

What needs release notes

  • New auth methods (passkey, social provider).
  • Policy changes (MFA now required for X).
  • UI changes affecting flow.
  • Email template updates.
  • Security improvements (password breach checks).

Bug fixes typically: silent.

Template

# Release X.Y.Z, 2026-05-13

## Summary
- WebAuthn / passkey support is now live.
- Improved password strength meter.
- Bug fixes.

## New
### Passkey support
You can now sign in with a passkey (Touch ID, Face ID, Windows Hello). 
Settings → Security → Set up passkey.

[Learn more](/docs/cookbook/auth-flows/feature-detect-passkeys)

## Changed
### Password strength meter
The password strength meter now uses zxcvbn for more accurate feedback.
Common passwords are detected and disallowed.

## Security
- Sessions are now revoked when password changes.
- Two-factor codes are checked against a stricter time window.

## Migration
No action needed. Existing users:
- Will see passkey option in next sign-in.
- Should consider enrolling for better security.

## Deprecation
None.

Sections

Summary

1-2 sentences. What's the headline?

New

User-facing additions. Include link to docs.

Changed

Existing behavior modified. Note what changed AND impact on users.

Security

Improvements worth highlighting separately. Builds trust.

Migration

If users need to do anything, say so clearly.

Deprecation

Coming changes. Give time for action.

Tone

User-facing language. Not developer-speak.

GOOD: "You can now sign in with a passkey."
BAD: "Added WebAuthn assertion handling via /self-service/login/code flow."

Where to publish

Multiple channels:

  • /changelog page in your app.
  • In-app banner ("What's new").
  • Email to active users.
  • Status page.
  • Blog post (for major).

In-app banner

{user.last_seen_release < currentRelease && (
  <Banner intent="info">
    What's new: passkey support is now available. <Link href="/changelog">See details</Link>
  </Banner>
)}

Dismiss after viewing.

Per-feature opt-in

Sometimes notes invite users to try:

### Try passkey sign-in

Settings → Security → Set up passkey

Save your passkey now to make signing in faster and more secure.

CTA in release notes.

Don't surprise users

For impactful changes, give warning:

30 days before:
"Starting June 1, all admin accounts require 2FA. Enroll now."

7 days before:
"Reminder: 2FA enrollment ends June 1."

Day 0:
"2FA is now required for admin accounts."

Pre-announce. Avoid lockouts.

Major version

For breaking changes (rare in auth):

# Major Release v2.0, 2026-12-01

## What's changed
- Token format is now JWT (was opaque).
- Issuer URL changed: https://auth.your-domain.com.

## Action required
Update your apps:
1. Use new issuer URL.
2. Update JWKS endpoint.
3. Test before December 1.

[Migration guide](/docs/migration/v1-to-v2)

Bold. Hard deadlines. Step-by-step.

Versioning

Semantic:

  • 1.0.0 → 1.0.1: patch (bug fix).
  • 1.0.1 → 1.1.0: minor (new feature, backward compat).
  • 1.1.0 → 2.0.0: major (breaking).

User-facing notes: focus on minor + major. Patches usually silent.

Per-tenant filtering

In white-label, customize per-tenant:

const notesForTenant = await loadNotes(tenant.id);

Some changes are global; some only affect specific tenants.

Archive

Past notes accessible:

  • /changelog/2026-05-13
  • /changelog/2026-04-22

Searchable. Linkable. Customers can verify "when did X change?"

Markdown source

Notes in markdown files:

changelogs/
├── 2026-05-13.md
├── 2026-04-22.md
└── ...

Versioned. Reviewable in PRs.

# Each PR with user-impact: add to changelog
- [ ] Changelog entry added

Code review checklist.

RSS feed

For developers / integrators:

<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>Olympus changelog</title>
    <item>
      <title>Passkey support</title>
      <pubDate>Tue, 13 May 2026 ...</pubDate>
      <link>https://your-domain.com/changelog/2026-05-13</link>
      <description>...</description>
    </item>
  </channel>
</rss>

Subscribe to stay updated.

Don't pad

Quiet weeks = quiet changelog. Don't invent.

If you do release infrastructure / internal changes (no user impact), separate:

# Engineering notes (no user-impact)
- Migrated to Bun 1.2.
- Refactored audit logger.
- Updated Postgres to 16.4.

Different audience.

On this page