Changelog Entry

A structured release entry naming what was added, changed, fixed, or removed in a given version - grouped by impact class under a version heading.

Changelog Entry

A changelog entry is the structured short form of a release announcement. It lives under a version heading and groups items by impact class (Added, Changed, Fixed, Deprecated, Removed, Security). The grouping itself is the load-bearing convention: it lets a reader answer “did anything break for me” and “did anything I wanted get fixed” in seconds.

Canonical template

## [Version] - YYYY-MM-DD

### Added
- [New feature, described from the user's perspective] (#PR)

### Changed
- [Behavior change that does not break existing usage] (#PR)

### Deprecated
- [Feature scheduled for removal in a future version, with migration note] (#PR)

### Removed
- [Feature deleted in this version, with migration note] (#PR)

### Fixed
- [Bug fix, described from the user's perspective] (#PR)

### Security
- [Security fix, often with CVE link or advisory link] (#PR)

When to use

Use a changelog entry for software release notes, version migration docs, and library upgrade guides where users need to scan impact quickly. Each version gets one entry; entries accumulate in a single CHANGELOG.md with newest at the top.

When not to use

Do not use this format for marketing-style release announcements (write a long-form blog post instead). Do not use it for internal team status updates. Do not paste a git log and call it a changelog - the grouping by impact class is the whole point.

Pairs well with

technical-writer, matter-of-fact, decision-log

Often confused with

meeting-notes: Meeting notes capture discussion that happened in a meeting; they are organized by topic and time. A changelog entry captures what changed in a software release; it is organized by impact class. The two share a “structured short form” feel but serve completely different purposes.

Instruction

Write a changelog entry for a software release. Use a version heading in the form
"## [VERSION] - YYYY-MM-DD". Group items under the six standard subsections: Added, Changed,
Deprecated, Removed, Fixed, Security. Omit empty subsections. Each item should be one line,
written from the user's perspective (what changed for them), and linked to the underlying PR or
issue where possible. Use matter-of-fact tone. Do not editorialize, do not market, do not narrate.
If an item is a breaking change, say so explicitly and include a migration note.

Template

See the Changelog Entry template.

Related

Pairs well with

Technical Writer, Matter of Fact, Decision Log

Avoid with

Storyteller, Narrative Case Study

Often confused with

Meeting Notes

Examples

Should we adopt async-first standups?

Team Standup Process - Changelog

All notable changes to this team’s standup ritual are documented here. Versioning loosely follows SemVer: breaking ritual changes bump the major version.

[2.0.0] - Async-first trial

Major change to how the 11-person team running across 4 timezones runs standups. This release ends the daily sync standup and replaces it with a written async post plus a single weekly working session. A 30-day trial period begins with this release.

Added

• Async standup post in #team-standup, due by 10am local time, using a fixed three-field template (Shipped / In progress / Blocked or at risk).
• Slack shortcut /standup that pre-fills the three-field template.
• Thursday working session, 60 minutes, 8am Pacific / 8:30pm IST. Cancellable by Wednesday 5pm Pacific if there is no agenda.
• On-call engineer is now responsible for triaging @mention blockers in #team-standup within the workday. New on-call section added to the playbook.
• Trial retro doc at docs/trial-retro.md for capturing mid-trial feedback in one place.

Changed

• On-call engineer’s morning responsibility shifts from running the sync standup to scanning the async channel once between 10am and 11am Pacific.
• “Blocked” became “Blocked or at risk.” We were under-reporting because nothing felt fully blocked until it was too late.
• Engineering manager’s role on Mondays moves from facilitator to async reader. Office hours added Tuesday afternoon for 1:1 follow-ups.

Deprecated

• “Quick sync after standup” sidebars. If something needs a 1:1, schedule it; do not assume the standup hangover provides one.

Removed

• Daily 9am Pacific sync standup. The recurring calendar invite has been deleted from all 11 calendars.
• Manual standup notes doc. Async posts in Slack are now the source of truth and are searchable via channel history.
• Round-robin status order. There is no order in async; people post when they start their day.

Migration notes

• Engineers in IST: you get your evenings back. The 9:30pm slot is yours again.
• Engineers in US Pacific and Eastern: your first 30 minutes of the day are now writing instead of talking.
• If you forget to post by 10am local, the on-call will @mention you. Two missed posts in a week triggers a check-in, not a punishment.

[1.4.2] - Previous release

• Fixed: timezone display in the standup notes doc was showing PST year-round during daylight saving.

[1.0.0] - Initial sync standup process

• Daily 9am Pacific standup, 15-minute time box, round-robin order, notes captured in a shared doc.

How to start a morning routine

My Morning Routine - Changelog

A running log of changes to my personal first-hour protocol. Versioning is loose but real: a major bump means the structure changed, a minor bump means a step was tuned, a patch bump means I noticed a small thing.

[3.0.0] - The four-step protocol

The first protocol I have actually stuck to for more than two weeks. This release reorganizes the entire morning around a fixed sequence and bans the phone from the first 35 minutes after waking.

Added

• Water step. 500ml within 5 minutes of waking. The glass goes on the nightstand the night before, which removed the only excuse I had been using.
• Light step. 10 minutes outside, or by an open window when weather refuses. Counts as light only if there is no screen between me and the light source.
• Planning step. 10 minutes with paper and pen. Top three for the day, written before any Slack or email exposure.
• Daily log row in log/days.csv. Single row, six columns. Done as part of the planning step, on the same page.

Changed

• Wake time fixed at 6:15. Previously drifting between 6:00 and 7:00 depending on the night before. The drift was doing more damage than the lost sleep.
• Movement reduced from 30 minutes to 15. The longer block was the reason I skipped the routine entirely on tired days. A 15-minute floor turns out to be more sustainable than a 30-minute aspiration.
• Coffee is now after planning, not before. Caffeine before water and light made me jittery and unfocused. Now it bookends the protocol instead of replacing it.

Deprecated

• The 5:30 wake attempt. Beautiful in theory, unkind to my actual sleep need. Keeping it documented in notes/abandoned/ for archaeology.

Removed

• Phone in the first 35 minutes. This was the hardest one and the highest-impact. The phone now lives charging in the kitchen overnight, not on the nightstand.
• Morning email triage. Moved to 9:15am as the first work block. Email was masquerading as planning; planning needs paper.
• Optional steps. v2.x had a stretch step that was sometimes there, sometimes not. Optional became “skipped.” The whole protocol is now mandatory or I have not done it.

Fixed

• The “I will start tomorrow” loop. Counting partial mornings as completed-with-asterisk fixed the all-or-nothing failure mode.

Migration notes

• I moved the phone to the kitchen on a Sunday night and could not reach it from bed. That is the migration.
• Family is already used to me being weird in the morning, so no comms needed there.

[2.4.1] - Patch

• Fixed: 6am cold water on the face was not waking me up faster, it was waking up my sinuses. Removed.

[2.0.0] - The “wake up earlier” attempt

• Tried 5:30 wake. Lasted 11 days. Got more tired, not less productive. Filed under “lessons.”

[1.0.0] - The original

• Wake, check phone, scroll, get dressed, leave. The default. Documented here only so the changes have a baseline.

How to choose between Postgres and DynamoDB for a new service

CHANGELOG - notification-service

[0.1.0] - 2026-05-22

First internal release of the Lattice Notify real-time notification service. Datastore selection (Postgres vs DynamoDB) was concluded at the Wednesday 2026-05-13 architecture meeting; the Friday sprint plan is built on this release.

Added

• Notification storage backed by Postgres (notifications schema in the primary cluster) (#142)
• Job queue using pg_notify plus a notification_jobs table for fanout work (#143)
• Read replica routing for fanout reads to absorb the 500K events/day launch load (#144)
• Datastore decision recorded in ADR-0023 with a 5M events/day revisit threshold (#145)
• Dashboard for notifications.write_rate, notification_jobs.queue_depth, and replica lag (#146)
• On-call runbook section for notification-service incidents, owned by the 4-person rotation (#147)

Changed

• Sprint plan for 2026-05-25 week reorganized around the Postgres path; previous DynamoDB spike work archived under spikes/dynamodb-2026-05/ (#148)
• Capacity-planning doc updated to reflect Postgres-only scaling milestones (#149)

Deprecated

• DynamoDB spike code in experiments/notify-ddb/ deprecated; will be removed in 0.3.0 once the Postgres path has 30 days of clean production data. Migration note: no production traffic ever ran on this path, no data migration is required (#150)

Removed

• The temporary in-memory notification buffer used during the spike phase is removed; all writes now go through the Postgres path (#151)

Fixed

• Fixed a race condition in the spike-era fanout logic where two replicas could double-deliver the same notification under load (#152)
• Fixed missing index on notification_jobs.created_at that caused queue-drain queries to fall back to sequential scan (#153)

Security

• All notification payloads encrypted at rest via existing Postgres TDE configuration; no additional KMS surface introduced (#154)
• New on-call playbook step requires confirming PII redaction in notification logs before any debug export (#155)