Documentation and releases
Documentation
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
Changelog
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/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 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 https://gitlab.com/ligolang/ligo/-/releases and pushing images to docker.