Each sprint should have its own version number.

Sigmah follows a x.y.z version scheme:

• x is a major version, including major changes in the code base (technical stack replacement, major refactoring, UI revamping…)
• y is for an evolution whenever database schema changes or any other breaking changes beyond a drop-in update
• z is for others evolutions

At the end of a sprint, result should be released as release candidate (rc). If the release candidate version if rejected, a new release candidate version has to delivered. And this processe loops until a release candidate is accepted.

At the end of the process, when the release candidate is accepted, the software is released a last time with the final release number (without “rc*” in its version number), and the source code repository is tagged with the final version number as well.

In the issue tracker, release candidates are not followed independently, and all tickets must be attached to the full version number associated with the sprint, not to the release candidate one.

• Sprint 3 is planned to output version 0.6.3.
• At the end of the sprint, the team delivers v0.6.3rc1 . Both the software and the source code repository are tagged with label “v0.6.3rc1”.
• A few minor bugs are detected in this version. Issue tracking tickets are not yet closed, and the team produces a few more commits linked to open tickets attached to targeted version 0.6.3 in the roadmap. The team delivers a new version v0.6.3rc2 . Both the software and the source code repository are tagged with label “v0.6.3rc2”.
• This version is finally accepted. The team delivers the final version v0.6.3 for this sprint, and both the software and the source code repository are tagged with the final label “v0.6.3”.