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
package: extra_files: - CHANGELOG.md - LICENSE - README.md
You can now proceed to set up GitLab CI.