You can use the following checklist to prepare for publishing a package to the registry for the first time, as well as for subsequent updates.
contact_emailshould be a valid email address which you regularly check. It is not normally used, but the registry maintainer may use it to contact you if necessary.
- Check that
descriptiongives a brief, up to date, accurate presentation of what your package does.
- Also check
- Check that
urlis up to date.
- Check that your GitLab repository is publicly available.
- It is recommended to add a
CHANGELOG.md(they are used by the user interface of the registry), but they are not required.
Nitrile relies on semantic versioning. This means that
packages have a version
MAJORincreases with incompatible API changes.
MINORincreases when functionality is added in a compatible way (including adding exported symbols, which may cause name clashes).
PATCHincreases with backwards compatible bug fixes.
Make sure that the version in
nitrile.yml is updated accordingly prior to publishing.
A number of projects in the registry are licensed under a copyleft license (e.g. GPL or AGPL). If your project links with such a dependency, it will need to be licensed under the same or a compatible license.
Including the right files¶
- Before publishing your package, run
nitrile packagelocally. Inspect the resulting tarball to ensure that it contains all the necessary files (and not too many).
- In most cases, you will want to include files like
CHANGELOG.mdin your package. Do this with
Special files and directories¶
In principle you are free to structure your packages how you see fit. However, a number of files and directories have a special function:
binshould contain executables that can be run by the user. These are exposed in
$PATHwhen the package is installed globally, and are available with
exeshould contain executables that should not be run by the user directly. Examples are the code generator or the iTasks post-linker.
libshould contain public modules of libraries; these are added to the include path of build tools.
misc/dllcan be used to distribute DLLs that are needed to build applications with the library. (DLLs that are needed to run executables in
exeshould be added to those directories, however.)
misc/srccan be used to distribute source files (most commonly C headers) that can be used by users of the library.
- There should not be a file
.nitrile.json, as this is used internally.
You can now proceed to set up GitLab CI.