Version: 0.42.1

Documentation and releases


If you'd like to contribute to the docs you can find them at gitlab-pages/docs in raw markdown form. Deployment of the docs/website for LIGO is taken care of within the CI, from dev and master branches.

Submitting your changes#


We're using our own implementation of GitLab's changelog model.

In short, it involves the following procedures:

  • Entries are located in ./changelog folder.

  • They are generated with a script (./scripts/, and they are YAML files with the following format:

title: string
merge_request: int
author: string
type: added|fixed|changed|deprecated|removed|performance|other

Obviously, you can add those files manually too if you want.

  • Any API change must have a changelog entry. Example: "Removed list_iter function"
  • Any user-facing change should have a changelog entry. Example: “Improved error reporting for ReasonLIGO”
  • Performance improvements should have a changelog entry.
  • Any docs-only changes should not have a changelog entry.
  • A fix for a regression introduced and then fixed in the same release should not have a changelog entry.
  • Any developer-facing change (e.g., CI, refactoring, technical debt remediation, test suite changes) should not have a changelog entry. Example: “Refactor nix expressions for webide”

Releases & versioning#

Development releases (next)#

Development releases of LIGO are tagged next and are built with each commit to the dev branch. Both the docker image & the website are published automatically.

Stable releases#

Stable releases are tags of form x.x.x, generally sticking to semver conventions. Such tags are automatically built on CI, producing a release in and pushing images to docker.