diff --git a/community/contribution_guidelines/index.html b/community/contribution_guidelines/index.html index 03809b58d..4480248be 100644 --- a/community/contribution_guidelines/index.html +++ b/community/contribution_guidelines/index.html @@ -6,6 +6,6 @@ $ ctest --test-dir serve -C docs/mkdocs
The documentation will then be available at http://127.0.0.1:8000/. See the documentation of mkdocs and Material for MkDocs for more information.
Before opening a pull request, check the documentation like the CI does:
make build -C docs/mkdocs # strict build: fails on broken links, anchors, and structure problems
make check_mermaid -C docs/mkdocs # checks the Mermaid diagrams (requires Node.js)
-A new API page also needs an entry in docs/docset/docSet.sql, the search index of the docset; make build reports missing entries.
The single-header files single_include/nlohmann/json.hpp and single_include/nlohmann/json_fwd.hpp are generated from the source files in the include/nlohmann directory. Do not edit the files directly; instead, modify the include/nlohmann sources and regenerate the files by executing:
make amalgamate
+The search index of the docset is generated from mkdocs.yml and each page's title (H1) and declaration by docs/docset/generate_docset.py; make build reports API pages that cannot be classified.
The single-header files single_include/nlohmann/json.hpp and single_include/nlohmann/json_fwd.hpp are generated from the source files in the include/nlohmann directory. Do not edit the files directly; instead, modify the include/nlohmann sources and regenerate the files by executing:
make amalgamate
Running make amalgamate will also apply automatic formatting to the source files using Artistic Style. This formatting may modify your source files in-place. Be certain to review and commit any changes to avoid unintended formatting diffs in commits.
If you add, rename, or remove a header in include/nlohmann, also regenerate the header list in BUILD.bazel (requires CMake) by executing:
make BUILD.bazel
The amalgamation check in CI fails if any of these generated files is out of date.
Certain contributions are not helpful.
We take pride in the library being used by numerous customers across various industries. They all rely on the guarantees provided by semantic versioning. Please do not change the library such that the public API of the 3.x.y version is broken. This includes:
What is and is not covered by this guarantee is described in the roadmap.
Although these guidelines may seem restrictive, they are essential for maintaining the library’s utility.
Breaking changes may be introduced when they are guarded with a feature macro such as JSON_USE_IMPLICIT_CONVERSIONS which allows selectively changing the behavior of the library. In next steps, the current behavior can then be deprecated. Using feature macros then allows users to test their code against the library in the next major release.
This library is designed to work with C++11 and later. This means that any supported C++11 compiler should compile the library without problems. Some compilers like GCC 4.7 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support.
Please do not add features that do not work with the mentioned supported compilers. Please guard features from C++14 and later against the respective JSON_HAS_CPP_14 macros.
Please refrain from proposing changes that would break JSON conformance. If you propose a conformant extension of JSON to be supported by the library, please motivate this extension.
The following areas really need contribution and are always welcomed:
json.hpp header, and I am not aware of approaches similar to re2c for parsing.We look forward to your contributions and collaboration to enhance the library!