Skip to content

Development and Release guidelines

Jump to bottom
Gonzalo José Carracedo Carballal edited this page Jul 17, 2020 · 1 revision

Development and release guidelines

SigDigger is a project in active development and, among other things, lacks a stable API. API stabilization is a huge task and has to be broken down into multiple minor tasks. In the meantime, additional features have to be added to SigDigger. We therefore propose the following branching paradigm:

  • next: Changes that break the API. Updated from develop for hotfixes or new features.
  • develop: maintenance branch. ABI can be broken, but not the API. Updated from master for hotfixes.
  • master: release branch.

Development process:

  • Non-API-breaking features are written in separate branches derived from develop named feature/<name>, with <name> a descriptive name for the feature. PRs are sent to BatchDrake, who performs the code review and merges them back to develop.
  • API-breaking features are derived from next instead. The process is otherwise the same.

Relationship to the Mercurial model:

  • Our master is equivalent to Mercurial's stable. This is the branch used for releases.
  • Our develop is equivalent to Mercurial's default. This is where changes and new features get accumulated before the next minor release.
  • We don't have anything equivalent to committed, apart from feature branches. Every feature branch has to be tested before merging it into develop.
  • Our next release has no equivalent to anything in Mercurial. It will be used for code changes that break the API. Right now, the only API-breaking changes we expect are those from API rationalization/stabilization tasks.

Versioning scheme

A new version is released when changes are merged back to master. This implies bumping the version numbers. Bumping a version number implies resetting to zero the least significant numbers according to the following rules:

  • When to bump the release number: after cherry-picking hotfixes from develop or extending device support in any platform.
  • When to bump the minor version number: after merging all changes (including new features) to master.
  • When to bump the major version number: after stabilizing the API.

The versioning scheme may change after SigDigger 1.0.0, as a stable API will require a more careful approach.

Clone this wiki locally