NRF SDK 0.9Maintenance
Prepare and distribute a version
Produce a verified package, explain compatibility and distinguish building, testing and publishing.
Build distribution files
Prerequisite: a Native project with valid tests and resources. Choose a version in mod.json, then generate the package. The plugin runs the tests and native verification required for this distribution.
.\gradlew.bat packageMod| Output file | Use |
|---|---|
| build/gradle/distributions/<modId>-<version>-windows-x64.zip | Release package with a <modId>-<version> root directory. |
| project.json · project-windows-x64.json | Package descriptors: identity, compatibility, calculated size and SHA-256. |
By default, the descriptor url field is the local ZIP name. The plugin does not upload files or install them in the game. A built package becomes a distributed version only after testing and explicit publication.
Describe a verifiable version
- Keep mod, model and setting identifiers stable. Change the package version when its contents change.
- Declare an sdkMin that covers the APIs actually used and a tested sdkMaxExclusive upper bound. A range accepted by the build does not prove every in-game behaviour.
- Validate the exact package to be distributed, using the same SDK and game executable. Retain the ZIP and its reports together.
- Write French and English release notes describing observable changes, compatibility and known limits.
Understand what the Hub discovers
A local build does not automatically register a new project in a public catalogue. For Hub distribution, prepare the files and metadata required by the chosen catalogue. Official NRF repositories have their own publication process; it is not an SDK API for all authors.
For projects offered by the Hub, version discovery depends on the catalogue and selected channel. A visible version, its download and its activation are distinct steps. Check the stated compatibility and active profile before concluding that a mod has been replaced.