Bissetii relies on various continuous integrations to ensure it is tested and verified. They are automated and operate under a single process chain for easy development. This is for quality assurance.
Bissetii only uses CI pipelines to manage releases and to test its application. As for human perception design testing, manual documentations are used to test all the visual output.
Bissetii uses ZORALab’s Fennec Project to unilaterally execute its GitLab CI automation. Hence, most of the deployment complies to Fennec specifications.
Bissetii uses point-release strategy to manage its releases progressively.
Its tags system follows semantic versioning with starting
Tags with tailing
+ is reserved for packaging releases by builds. Usually,
this type of tagging (with or without
+ sign) happens on
Tags with tailing
~ is reserved for packaging release candicates. Usually,
this type of tagging happens on
staging branch. Example:
Tag with tailing
- is reserved for package maintainer only (e.g. Debian
developers/maintainer). Hence, we should not use it to avoid
unnecessary collision. Example:
Bissetii follows the 3 branches (
and progressive development. This means that we do not perform git revert
or rebase to break any timelines.
This branch is known as the main product line. It is protected and recognized as the final product.
staging branch is allowed to merge into
master branch and there
SHOULD NOT be any development on this branch.
This branch is known as the next product release. It holds all the commit patches for the next release and is currently under testing.
It should carries the same commit timeline as
master branch and holding
the future commits to be merged into it.
ONLY maintainers are allowed to commit and cherry-pick commit patches into this branch.
This branch is known as the edge. It contains all the latest and greatest development. Any contributors can contribute here.
As for the website publishing, it is tracked under this branch for documentation flexibility without triggering a minor release.