# Adminive Release Policy

## Dependency model

Adminive intentionally uses two dependency modes:

- Source-tree build/test mode: nlohmann/json 3.12.0, magic_enum 0.9.8, and cpp-httplib 0.48.0 use pinned bundled headers under `backend/service/third_party/include`.
- Installed-package mode: adapter components use external CMake packages. The bundled headers are not installed into the consumer's generic include namespace.

Structive may be checked out under `third_party/Structive` for a standalone Adminive source tree or maintained as a sibling checkout selected by `ADMINIVE_STRUCTIVE_SOURCE_DIR`. The source archive always stages the selected Structive release files under `third_party/Structive`, without copying repository history or verification output into either working tree.

Installed component dependencies are:

| Adminive component | External dependency |
|---|---|
| `Core`, `Http`, `Service` | none beyond the exported Adminive/Structive headers |
| `Nlohmann` | `nlohmann_json` >= 3.12.0 |
| `MagicEnum` | `magic_enum` >= 0.9.8 |
| `Httplib` | `httplib` >= 0.48.0 |
| `BoostPfr` | Boost headers |
| `Drogon` | Drogon |
| `Default` | nlohmann_json, magic_enum, cpp-httplib |

This split prevents Adminive installation from shadowing a consumer's own `<nlohmann/...>`, `<magic_enum/...>`, or `<httplib.h>` headers while keeping repository builds reproducible.

## License metadata

`THIRD_PARTY_NOTICES.md` and `third_party/licenses/` describe redistributed third-party code. The source tree does not currently declare an outbound license for Adminive or Structive project-owned code. Adding or changing that project license is a separate owner decision and must not be inferred from third-party licenses.

## Drogon release gate

Normal tests use the lightweight fake Drogon contract fixture. A release machine with real Drogon and nlohmann_json CMake packages installed must additionally run:

```text
python scripts/verify.py --real-drogon
```

`ADMINIVE_ENABLE_REAL_DROGON_TESTS=ON` builds a real-Drogon adapter compile/run target and an installed-package consumer. This gate exists specifically to catch changes in real Drogon route/callback/constraint APIs that the fake fixture cannot detect.

## Release checklist

1. Run focused tests for changed Core/adapter/protocol code.
2. Run Debug and Release CTest suites.
3. Run install-consumer and package ZIP tests.
4. Run sanitizer gates supported by the compiler.
5. Run `python scripts/verify.py --real-drogon` on a release environment with real Drogon packages.
6. If frontend code changed, run frontend unit, production build, Chromium E2E, and Edge E2E on Windows.
7. Run `npm --prefix frontend audit --omit=dev`; eliminate direct and critical findings where a compatible fix exists, and document unfixed upstream exposure instead of using an unverified forced major upgrade.
8. Verify the installed prefix contains Adminive headers and release/license metadata but not bundled nlohmann/json, magic_enum, or cpp-httplib headers.
9. Generate the source archive without build output and with China Standard Time timestamps.