Skip to content

docs: User Guide: include a note about REQ_PREFIX -> PREFIX migration #2308

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 7, 2025
Merged

docs: User Guide: include a note about REQ_PREFIX -> PREFIX migration #2308

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions docs/strictdoc_01_user_guide.sdoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -621,8 +621,8 @@ The following ``DOCUMENT`` fields are allowed:
* - ``CLASSIFICATION``
- Security classification of the document, e.g. Public, Internal, Restricted, Confidential

* - ``PREFIX``
- Requirement prefix that should be used for automatic generation of UIDs. See [LINK: SECTION-UG-Automatic-assignment-of-requirements-UID].
* - ``PREFIX (formerly REQ_PREFIX)``
- Requirement prefix that should be used for automatic generation of UIDs. See [LINK: SECTION-UG-Automatic-assignment-of-requirements-UID]. This field used to be called ``REQ_PREFIX`` but it was deprecated as of 2025-Q2. The ``REQ_PREFIX`` alias will be removed from the codebase in 2025-Q3.

* - ``ROOT``
- Defines whether a document is a root object in a traceability graph. A root document is assumed to not have any parent requirements. The project statistics calculation will skip all root document's requirements when calculating the metric ``Non-root-level requirements not connected to any parent requirement``.
Expand Down Expand Up @@ -650,7 +650,7 @@ STATEMENT: >>>
The ``OPTIONS`` field may have the following attribute fields:

.. list-table:: SDoc grammar ``DOCUMENT``-``OPTIONS`` fields
:widths: 20 80
:widths: 25 85
:header-rows: 1

* - **Field**
Expand Down Expand Up @@ -4192,6 +4192,8 @@ Using the new syntax, it is now possible to declare any custom composite element
2\) The previously used ``[SECTION]`` syntax with one square bracket around the SECTION is now DEPRECATED, but the old behavior is still supported. The users are encouraged to migrate all ``[SECTION]`` elements to the new ``[[SECTION]]`` syntax. To support the new behavior, the grammar must include a declaration for a composite SECTION element similar to the example provided above.

3\) The ``[COMPOSITE_REQUIREMENT]`` node has been removed from the codebase. This is a backward-incompatible change, but it is assumed that no users should be affected since this feature has never been developed enough to be useful.

4\) The document-level ``REQ_PREFIX`` has been renamed/aliased to ``PREFIX``. The REQ_PREFIX form will still be recognized but writing SDoc files back to disk will result in the new PREFIX field to be written.
<<<

[[SECTION]]
Expand Down
Loading