The Narraya Changelog: what changes, and how we say it
The Narraya changelog collects features, improvements, fixes and breaking changes. Public transparency, RSS feed, continuity for long novels.
The work that makes a piece of software reliable is, in most cases, invisible. A bug fixed on Thursday night doesn't make news; an optimization that loads a page in 300 milliseconds instead of 800 doesn't appear in newsletters. And yet those are precisely the interventions that, added up, distinguish a mature product from a sloppy one. The changelog exists to make that work visible — and out of respect for those who use Narraya every day.
What a changelog is
The changelog is a public list of all the changes released in Narraya, in reverse chronological order. You'll find it at /en/changelog. Each entry shows the release date, the type of change, and a brief description — enough to understand whether it concerns you, short enough to scroll through in a minute.
It isn't a technical diary meant for developers. It's a communication addressed to the authors using Narraya: what's new, what's been improved, what's been fixed, what's changed in how certain features behave.
The four entry types
Every change in the changelog is labelled. The classification, for those in a hurry, lets them jump to what matters: those looking only for new things skip the fixes; those attentive to stability check mostly the corrections.
| Type | What it means | Example |
|---|---|---|
| Feature | A new functionality, never existed before | "Added the Chapter Kanban" |
| Improvement | An existing feature that now works better, faster, or more clearly | "PDF export is now roughly three times faster" |
| Fix | A bug fixed: something wasn't working as it should, now it does | "Fixed an issue where nested lists lost indentation in DOCX export" |
| Breaking | A change altering the behavior of an existing feature. Always flagged prominently | "The character sheet now requires the Name field as mandatory" |
Breaking changes are the rarest — and also the most delicate. When a change alters how something used to behave, we communicate it in advance: by email to affected users, prominently in the changelog, and often with a "dual compatibility" period during which old and new coexist. We don't want you to open Narraya on a Monday and discover that a habit you built your sessions on has vanished without warning.
How to read the changelog
You don't need to read it in full every time. For most users, three approaches work well, depending on the moment:
- Weekly scan. Every Monday morning, two minutes: scroll the week's entries, see if anything new concerns you. It becomes a light habit.
- Occasional consultation. When a behavior seems to have changed, check the changelog. Often the answer is there, with the exact date and a short explanation.
- Overview after breaks. If you return to Narraya after a month of travel or of creative block, a reading of the last month of the changelog reorients you better than any newsletter could.
To avoid opening the changelog manually, there's a dedicated RSS feed. Add it to your preferred aggregator and you'll receive only the important updates — no emails, no push notifications. The feed link is at the bottom of the changelog page. A quiet way to stay informed: Narraya respects you in how it communicates too.
Why not put everything in release notes inside Narraya
A fair question: why a public changelog, rather than an "announcement of what's new" inside the application? For two reasons. The first is that many people don't want to be interrupted while writing by popups celebrating new features. The moment of writing is sacred; news can wait for the next coffee break. The second is that a public changelog is consultable even by those not yet users of Narraya: people evaluating the platform can see, transparently, how much we work on it and what we're doing.
Continuity for those writing a long novel
There's something we care about particularly: continuity. If you've been writing a novel in Narraya for eight months, the changes we introduce shouldn't scare you. For that reason, in the changelog you can always see the full list of what's been touched — and if anything concerns a feature you use, understand whether your workflow stays the same or whether you'll have to adapt it.
A good changelog is, in a way, a continuity contract between those who build the product and those who live inside it. We tell you everything. We explain what changes. We warn you in advance if something important is shifting. It's how a small project like ours can earn the trust needed to accompany novels that take years. We don't ask for blind trust: we build it entry by entry, in the changelog.
Check the updated changelog whenever you want. Subscribe to the RSS feed at the bottom of the page if you prefer an asynchronous, silent reading that respects your time.