Processes
7 processes described. A process is a sequence of steps the business or the tool follows, with the roles, screens and rules each step involves.
| Process | Execution | First line | Links |
|---|---|---|---|
| Release | human | How a version of the tool is cut and what it publishes: the npm packages under one shared version number and the preset, the container image tagged with the version and latest, a git tag v<major>.<minor>.<patch> on the main branch, a release whose notes are the changelog entries with the tarball of every package and the standalone binaries as assets, and the mirrors of the GitHub action and the GitLab component at the same version. Every form of one version names the same commit: the tag, the packages on npm, the image, the action, the component and the pre-commit hook. Versions follow semantic versioning; before 1.0.0 a minor version may break compatibility and says so, a patch never does. The release guide is the contract; the one decision that stays human is the merge of the version pull request, and the publications to the registries stay disabled until the maintainer enables them. | 34 |
| Adding a language pack | human | A language is described by data, never by code: a folder holding pack.yaml (the name of the language, its apostrophes, its collation options, its plural suffix rules, validated by the language pack schema) and stopwords.txt. The engine ships en and fr; a regional variant such as fr-CA uses the pack of its language until a more specific one is registered; any other language comes as a pack shipped by a plugin, registered when the plugin loads, and a locale with no pack is a build error. Every source selects its pack through its BCP 47 locale, which decides its comparison form, its default stopwords, its word segmentation and the collation of its indexes. The architecture guide states the design. | 27 |
2 processes of 2 — pagination by twenty. The Links column counts the related pages, which brings the most central processes of the journey to the top.