Education software release notes: shipping changes on the academic calendar

Somewhere right now a teacher is up at 11 p.m. on a Sunday, rebuilding a quiz in your product because class starts at 8. They did not choose your software — their district or university did — and they have built a semester of coursework on top of exactly how it works today. When you ship a change, you are not updating an app. You are editing the classroom of someone who was never asked and cannot postpone Monday.

That makes education software — LMS platforms, courseware, quiz and grading tools, classroom-management apps — one of the hardest release-communication problems there is. The audience spans professional administrators and nine-year-olds. The deployment calendar belongs to the school year, not to your sprint board. And the cost of a surprise is not a support ticket; it is a lecture hall full of students watching their instructor hunt for a button that moved overnight. This guide covers what to write, when to ship it, and how to reach the people standing in front of a class.

Three readers, one classroom

Every education release note has three readers with almost nothing in common, and each one needs a different thing from you.

  • The instructor is the reader who matters most and reads least. Time-poor, often non-technical, and mid-course: their question is never “what shipped?” but “will my course still work the way I built it?” Everything in the plain-language release notes guide applies double here — name what they see on screen, not what you refactored.
  • The institution admin — district IT, the university LMS team — is the reader who actually subscribes. They control rollout where you let them, field the help-desk tickets when you don’t, and brief instructors before term starts. They need precision: what changes, on what date, behind which toggle, with which default.
  • The student will never read a release note and should never need to. Students meet your changes mid-assignment, at the worst possible moment, with the highest stakes of anyone. You write for the first two readers so the third never notices anything happened.

The practical consequence: write the entry for the instructor, structure the details for the admin, and judge every change by what it does to a student two hours before a deadline.

The academic calendar is your release calendar

Retail has Black Friday; education has finals week, and it comes twice a year. A SaaS dateline stream that ships whenever CI is green is the wrong default here, because your customers’ capacity to absorb change is savagely seasonal:

  • Term breaks are when disruptive changes land. Summer and the winter break are your windows for anything that changes workflows or moves UI. Admins expect it; many institutions do their own upgrade testing then.
  • Mid-term is for fixes and invisible improvements. Shipping is fine; surprising is not. If an instructor would need to re-learn anything, it waits.
  • Exam periods are freeze windows. Nothing user-visible ships during finals. Many vendors freeze deployments entirely; all of them should freeze surprises. Say so publicly — a one-line freeze policy on your changelog page is worth more reassurance per word than anything else you will write.
  • The calendar isn’t universal. Northern and southern hemispheres invert the year; K-12, higher ed, and continuing education run different terms; international customers add more. You cannot find a week that is nobody’s crunch — which is exactly why advance notice with dates beats clever timing.

The core discipline is the announce-then-ship pattern with the school year attached: workflow changes are announced in an entry of their own, weeks ahead, with the arrival date stated in calendar terms an academic reader can act on — “arrives July 15, before fall term” — so admins can put it in their August instructor briefing instead of their October apology.

Your UI is course material

Here is the thing most vendors miss: instructors photograph your product. Screenshots of your interface are frozen into syllabi, slide decks, how-to handouts, LMS help pages, and tutorial videos that institutions produced once and reuse for years. When you move a button, you don’t just change your app — you silently invalidate teaching materials you have never seen, and the instructor finds out from a confused student’s email.

You cannot stop screenshotting, so write for it instead:

  • Flag visual moves as loudly as behavior changes. “The Submit button moved from the bottom of the page to the top right” is a headline fact for this audience, not a cosmetic footnote. The before-and-after screenshot is the single highest-value artifact you can attach — it lets an instructor update their handout in one glance.
  • Name locations the way a handout would. “Course Settings → Grading” matches what’s printed in a thousand PDFs; “the settings panel” matches nothing.
  • Link the updated help article in the entry. Most institutions link vendor help docs from their own materials; if your docs update the same day, half the downstream repair happens for free.
  • Maintain a “what moved” list for big releases. A summer redesign should ship with a table of old location → new location. Admins turn that table directly into their instructor training.

Features your institutions toggled

Education software is administered software: most LMS features can be enabled, disabled, or defaulted at the institution level. That means a release note that says “you can now do X” is wrong for every reader whose admin has X turned off — and a teacher who excitedly plans a lesson around a feature they don’t actually have will not trust your notes again. The discipline comes from the feature-flag release notes guide, with an institutional twist:

  • State the toggle state in the entry. “Off by default; institution admins can enable it under Admin → Features” tells both readers the truth at once.
  • Announce default flips as changes. Flipping a feature from opt-in to on-by-default is a release for every institution that hadn’t opted in — it gets its own dated entry and advance notice, never a silent switch mid-term.
  • Give admins an opt-in window before a forced migration. The standard pattern — new experience opt-in for a term, default the next term, old experience removed the term after — works because it maps to the academic calendar. Publish the schedule once and repeat it in every related entry.

Grading and submissions: the third rail

Some surfaces of an education product carry academic consequences, and changes to them are breaking changes no matter what your API diff says: submission flows, due-date and late-penalty handling, gradebook calculations, quiz timing and accommodations, academic-integrity tooling, and notification behavior. A rounding change in grade calculation is not a bug fix — it changes students’ grades. A submission-button redesign the night before a deadline is not a UI refresh — it is the reason a student misses a cutoff and files an appeal.

For this class of change, the bar is the highest in the product:

  • Advance notice, always — announced ahead with dates, per the breaking-changes playbook, and never landed mid-term.
  • Exact before-and-after behavior. “Late penalties now apply per day instead of per hour; a submission 3 hours late was previously penalized 3%, now 10%” — numbers, not adjectives, because instructors must be able to answer student challenges precisely.
  • A verification step for instructors. Tell them how to confirm their course is unaffected: “Check Course Settings → Grading; if your late policy shows ‘per day,’ nothing changes.”
  • A known-issues section during exam periods. If anything is wrong with submissions or grading, saying so prominently is the difference between a help-desk flood and a forwarded status link.

Where notes actually reach a classroom

The delivery problem is a relay: you can reach admins directly, but instructors are reached mostly through admins, and students only through instructors. Layer accordingly:

  • A canonical release-notes page with per-entry permalinks and feeds. Admins subscribe by email digest or RSS; help desks link individual entries in ticket replies; the permalink is what survives into an institution’s own training materials.
  • Advance-notice entries written to be forwarded. The most common thing an LMS admin does with your release note is paste it into their own instructor newsletter. Write the summary paragraph so it survives that copy — self-contained, dated, jargon-free.
  • In-product announcements that respect teaching. A what’s-new indicator is fine on a dashboard; a modal is never fine in front of a class, and nothing user-visible should ever interrupt an in-progress quiz or submission. Education is the strongest case anywhere for the never-a-modal rule.
  • Instructor-facing changes surface at point of use. A small “this page changed — see what’s different” note on the redesigned page itself, for the first weeks of term, reaches the instructor who reads nothing else.

Accessibility and privacy are announcements

Two categories of change that vendors habitually under-announce are, for schools, procurement-grade news. Accessibility fixes deserve loud, specific entries — educational institutions are legally required to provide accessible tools, accessibility offices actively track vendor progress, and a dated public trail of WCAG fixes is evidence your sales team will reuse; the accessibility release notes guide covers the craft. And anything touching student data — new data collection, changed retention, a new subprocessor — is a policy change that FERPA-conscious districts must evaluate; burying it in a feature roundup reads as concealment to exactly the reader whose trust funds renewals. Both audiences overlap with the enterprise release-notes reader: institutions are enterprises with legal departments and term-shaped change windows.

An entry template

A shape that serves all three readers at once:

New quiz builder arrives July 15 (before fall term)

Who’s affected: instructors who create quizzes. Students see
no change to how quizzes are taken.

What changes: quiz creation moves from Course Tools → Quizzes
to the new builder at Course Tools → Assessments. Existing
quizzes keep working unchanged. [Before/after screenshot]

Availability: opt-in per institution today (Admin → Features
→ New Quiz Builder); becomes the default January 5, before
spring term; the old builder is removed next summer.

For admins: enabling now lets you run instructor training this
fall. The old → new location table and updated help articles:
<link>. Grading behavior, due dates, and the gradebook are
unchanged in this release.

Action needed: none before January. Institutions using custom
quiz-creation training materials should plan updates this fall.

Note what the shape does: audience split first, screen locations named as a handout would name them, the toggle schedule in calendar terms, an explicit “grading unchanged” line for the nervous reader, and a forwardable admin paragraph.

Anti-patterns

  • The finals-week redesign. Any user-visible change during an exam period is a self-inflicted incident. The work being ready is not a reason; the calendar outranks your roadmap.
  • “Improved grading experience.” Vague notes about consequential surfaces force every instructor to assume the worst and re-verify their gradebook — or worse, not to. Name the exact behavior, before and after.
  • Admin-only release notes. If notes reach only the IT office and die there, instructors meet every change cold. Write the forwardable paragraph, provide the public permalink, and give instructors a subscription path of their own.
  • The silent default flip. Turning a toggled feature on for everyone without a dated announcement converts your most careful customers — the ones who deliberately hadn’t opted in — into your most surprised ones.
  • Screenshot-invalidating changes with no map. Moving UI without a what-moved list quietly breaks a decade of accumulated course materials and spends instructor goodwill you cannot buy back.
  • Version soup across hosting models. If you offer both cloud and self-hosted (the Moodle world), per the on-prem release notes guide: one changelog, explicit version-to-hosting mapping, and never notes that assume everyone is on the latest.

Running it on Wakelog

Wakelog fits the relay structure of education communication well. Scheduled publishing is the load-bearing feature: write the disruptive-change entry when the work merges in March, set publish_at to the summer release date, and the announcement lands exactly when the calendar allows. Tags split the audiences — instructors filter for what changes their classroom while admins watch everything — and per-entry permalinks are what help desks and instructor newsletters link. Feeds give district IT the subscription they actually want, and an unlisted project works as the support-team briefing stream. The honest boundary: Wakelog doesn’t know your customers’ term dates — the academic-calendar judgment stays yours; publish_at is how you act on it.

Start your changelog — free   Next: release notes for non-technical users →

Related guides

Last updated 2026-08-01 · All guides