Documentation and releases
#
DocumentationIf 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#
ChangelogWe'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/add-changelog-entry.sh), and they are YAML files with the following format:
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 releasesStable releases are tags of form x.x.x
, generally sticking to semver conventions. Such tags are automatically built on CI, producing a release in https://gitlab.com/ligolang/ligo/-/releases and pushing images to docker.