> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superoffice.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Add or update release notes

> How to add and update release notes across major versions, mobile, EOL announcements, and generated API and database notes.

Use this guide when you add or update files in *release-notes/*.

## Follow the format by version line

* SuperOffice **12 and newer** (the current major version) use the Mintlify [Update component][2] in the major-version `index.mdx` page, such as *release-notes/12/index.mdx*, and are the only version line that gets real content edits.

* SuperOffice **11 and earlier**, and **Pocket CRM**, should receive formatting updates only. Do not make content edits there. This applies regardless of which structural format a version happens to use: SuperOffice 11 now uses the same Update+Badge component as 12 (see `release-notes/11/index.mdx`), but it's a historical version, so it stays formatting-only just like 10.x and earlier.

* **Mobile CRM** uses the Update component too, split across *release-notes/mobile/v11.mdx* and *release-notes/mobile/v10.mdx*. See [Update mobile release notes](#update-mobile-release-notes) below.

* **Integrations** uses the Update component - one per integration.

## Write SuperOffice 12 and newer release notes

For each minor version:

* Add **one `<Update>` block** per minor version, latest at the top.
* Add **one H3 heading** per feature item inside that update.

When stepping to a new major version:

1. Create a new folder in *release-notes/*, for example `release-notes/13/`.
2. Add `index.mdx` for the new major version.
3. Add the new page to *config/nav-releases.json*.
4. Continue using the same Update-based structure.

<Tip>
  Use the release-notes-major-version [template][3].
</Tip>

### Badge map for feature headings

| Badge text               | Icon        | Color  | Example                                                              |
| ------------------------ | ----------- | ------ | -------------------------------------------------------------------- |
| Service                  | ticket      | green  | `<Badge icon="ticket" color="green">Service</Badge>`                 |
| Marketing                | bullseye    | purple | `<Badge icon="bullseye" color="purple">Marketing</Badge>`            |
| Sales                    | dollar-sign | blue   | `<Badge icon="dollar-sign" color="blue">Sales</Badge>`               |
| Core CRM                 | user        | blue   | `<Badge icon="user" color="blue">Core CRM</Badge>`                   |
| Settings and maintenance | gear        | orange | `<Badge icon="gear" color="orange">Settings and maintenance</Badge>` |

### Use stable anchors

Each minor update needs a persistent anchor:

```mdx theme={null}
<Update label="12.1" description="MM.DD.YYYY" tags={["Settings and maintenance"]}>
<a id="12.1"></a>
```

Each feature H3 can also define a [Mintlify anchor override][2] so you can deep-link to that specific feature:

```mdx theme={null}
### <Badge icon="gear" color="orange">Settings and maintenance</Badge> Feature title {#12.1-admin-1}
```

## Update mobile release notes

For Mobile CRM:

* Add **one `<Update>` block** to *release-notes/mobile/v11.mdx* (or *v10.mdx* for a v10.x backport), latest at the top. No new file and no new nav entry is needed for a routine update: both files are already wired into *config/nav-releases.json*.

* Add **one H3 heading** per feature inside that update, matching the plain-heading style already used there (no `<Badge>`: Mobile CRM is one product line, not a multi-module system, so it doesn't need a module badge per feature the way SuperOffice 12 and newer do).

* Use the file's existing `tags={[...]}` convention for filtering (for example `["Diary", "Follow-ups"]`), carried over from what used to be the file's `category`/`topic` frontmatter.

* Add screenshots with the `-app-screen` suffix in the image alt text, and place the image files in */media/loc/en/mobile/*.

* Give the update a stable anchor the same way as SuperOffice 12 and newer:

  ```mdx theme={null}
  <Update label="11.2.0" description="MM.DD.YYYY" tags={["Diary"]}>
  <a id="11.2.0"></a>
  ```

  When a version has more than one feature, add an explicit anchor to each feature H3 too, so it can be deep-linked individually: `### Feature title {#11.2.0-1}`.

* Add a bullet for the new update to the changelog list in *release-notes/mobile/index.mdx*, linking to the update's anchor (for example `./v11#11.2.0`).

* When mobile itself needs a fresh split (not simply because a new desktop major version ships), create the next file (for example *v12.mdx*), add it to *config/nav-releases.json*, and add a wildcard redirect in *config/redirects.json* for the version line it replaces.

## Update EOL announcements

EOL content is maintained independently of release-note updates.

To update EOL:

1. Edit *release-notes/eol/index.md*.
2. Add a row to the current or upcoming table.
3. Optionally link the first-column product or feature to a new dedicated page in `release-notes/eol/` if you need a detailed message.

## Leave generated API and database notes alone

API and database release notes are generated content, including `MAJOR/api/` such as *release-notes/12/api/*.

Do not hand-edit generated release-note files.

Generated files use their original generated filename (for example *changes-webapi-12.2.2072.0.md*) directly under `MAJOR/api/` - no per-version subfolder.

## Related content

* [Using Blueprint templates][3]
* [SuperOffice 12 release notes][6]
* [Mintlify Update component][4]

[2]: ./markdown-guide/links-in-docs#anchors

[3]: ./markdown-guide/using-blueprint-templates

[4]: https://www.mintlify.com/docs/components/update

[6]: /release-notes/12/index