Checklist

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.

Basics

  1. contact_email should 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.
  2. Check that description gives a brief, up to date, accurate presentation of what your package does.
  3. Also check name, maintainer, and version.
  4. Check that url is up to date.
  5. Check that your GitLab repository is publicly available.
  6. It is recommended to add a README.md and CHANGELOG.md (they are used by the user interface of the registry), but they are not required.

Versioning

Nitrile relies on semantic versioning. This means that packages have a version MAJOR.MINOR.PATCH, where:

  • MAJOR increases with incompatible API changes.
  • MINOR increases when functionality is added in a compatible way (including adding exported symbols, which may cause name clashes).
  • PATCH increases with backwards compatible bug fixes.

Make sure that the version in nitrile.yml is updated accordingly prior to publishing.

Licensing

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

  1. Before publishing your package, run nitrile package locally. Inspect the resulting tarball to ensure that it contains all the necessary files (and not too many).
  2. In most cases, you will want to include files like LICENSE, README.md, and CHANGELOG.md in your package. Do this with package:extra_files:
package:
  extra_files:
    - CHANGELOG.md
    - LICENSE
    - README.md

You can now proceed to set up GitLab CI.