Skip to content

Document the API stability guarantee in the roadmap - #5775

Merged
nlohmann merged 3 commits into
developfrom
docs-api-stability
Oct 7, 2026
Merged

nlohmann merged 3 commits into
developfrom
docs-api-stability

Conversation

@nlohmann

@nlohmann nlohmann commented Oct 7, 2026 •

Copy link
Copy Markdown
Owner

Users had no single place to look up what the 3.x API guarantee covers. The roadmap only said that releases follow semantic versioning, and the details were in the contribution guidelines, written as rules for contributors. Nothing said what is not covered, so users had to guess about exception message texts, sizeof(json), or nlohmann::detail (see discussion #3473).

This adds an API stability section to the roadmap:

  • What a 3.x release does not change: function signatures, function and class names, which exceptions are thrown and their ids, access specifiers, and default arguments.
  • What is not part of the public API and may change in any release:
    • the text of exception messages (what());
    • the ABI, including sizeof(basic_json) and the memory layout, with a link to the versioned inline namespace;
    • nlohmann::detail, and macros and type traits not documented in the API reference.
  • Breaking changes only come behind macros, with a link to the Version 4.0 section.

The roadmap's "Break the public API" item now links to this section. The "Break the public API" section of CONTRIBUTING.md keeps its rules for contributors and links to the roadmap for the guarantee.

API impact

No breaking changes. This is documentation only, and it describes existing practice: for example, exception messages have been improved in past releases.

Written by Claude Code.

🤖 Generated with Claude Code

Signed-off-by: Niels Lohmann <mail@nlohmann.me>
Signed-off-by: Niels Lohmann <mail@nlohmann.me>
@nlohmann nlohmann changed the title Document what is not covered by the API stability guarantee Document the API stability guarantee in the roadmap Oct 7, 2026
… release notes

Signed-off-by: Niels Lohmann <mail@nlohmann.me>
@nlohmann nlohmann added this to the Release 3.13.0 milestone Oct 7, 2026
@nlohmann
nlohmann merged commit e4e7d65 into develop Oct 7, 2026
4 of 166 checks passed
@nlohmann
nlohmann deleted the docs-api-stability branch October 7, 2026 06:49
Releases follow [semantic versioning](https://semver.org): a minor or patch release of version 3.x does not break code
that uses the public API. In particular, a 3.x release does not:

- change the signature of a function (its parameter types, return type, number of parameters, or the const-ness of a

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is too strict. New parameters may be added if they are defaulted.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. A new parameter with a default value is fine. The rule now only covers the types and order of existing parameters, see #5784.

Posted by Claude Code on behalf of @nlohmann.

member function);
- remove or rename a function or class;
- change which exceptions a function throws, or the [exception ids](../home/exceptions.md);
- change access specifiers or default arguments.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may add new defaults but not change existing ones.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. The rule now says that new default arguments may be added and existing ones may not be changed or removed, see #5784.

Posted by Claude Code on behalf of @nlohmann.

## API stability

Releases follow [semantic versioning](https://semver.org): a minor or patch release of version 3.x does not break code
that uses the public API. In particular, a 3.x release does not:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarification?

does not break code that uses the public API

without a macro opt-in as described below

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. The first sentence now says "unless that code opts in to a change with a macro" and links to the Version 4.0 section, see #5784.

Posted by Claude Code on behalf of @nlohmann.


- The text of exception messages returned by `what()`. Use the [exception id](../home/exceptions.md) to tell errors
apart.
- The ABI, including `sizeof(basic_json)` and the memory layout of its values. Recompile your code when you upgrade the

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recompile your code when you upgrade the library

That's a given because it's header-only, and different releases are not interoperable due to the versioning namespace as described in the next sentence.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. I dropped the sentence and kept only the one about the versioned namespace, see #5784.

Posted by Claude Code on behalf of @nlohmann.

nlohmann added a commit that referenced this pull request Oct 8, 2026
…5784)

* Address review comments on #5775 and #5779

Allow new defaulted parameters and new default arguments in the API
stability rules, mention the macro opt-in, and drop the redundant
recompile advice. Describe test-diagnostics-optimized as the regression
test for the fixed #5742.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

* Document what counts as a breaking change in the API stability rules

Spell out the 3.x compatibility rules in the roadmap: new defaulted
parameters, new default arguments, noexcept/constexpr, template
parameters, parse and dump results, accepted input, key iteration order,
iterator invalidation, implicit conversions, to_json/from_json lookup,
json_sax, value_t enumerators, and documented macros, CMake options and
headers. Also list std::hash values as not part of the public API, and
link the macro overview from the section.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

---------

Signed-off-by: Niels Lohmann <mail@nlohmann.me>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants