Versioning
DeepTab follows Semantic Versioning 2.0 and uses Conventional Commits to automate version bumps and changelog generation via commitizen.
Version format
MAJOR.MINOR.PATCH
Segment |
When it increments |
|---|---|
|
Breaking change ( |
|
New backwards-compatible feature ( |
|
Backwards-compatible bug fix ( |
Release candidates use the suffix rcN, e.g. 1.8.0rc1.
The version is defined in one place only, pyproject.toml, and read at runtime via importlib.metadata in deeptab/_version.py, so it never needs to be hard-coded in the package.
Commit types and their effect
Commit type |
Example |
Version bump |
|---|---|---|
|
|
Minor |
|
|
Patch |
|
|
Patch |
|
|
Major |
|
|
None |
|
|
None |
|
|
None |
|
|
None |
|
|
None |
|
|
None |
Commit messages that do not match any of these types do not trigger a version bump.
Making a conventional commit
Use commitizen’s interactive prompt rather than writing the message by hand:
just commit # opens the cz commit wizard
Or write the message directly:
git commit -m "feat(models): add NODE architecture"
git commit -m "fix(configs): validate n_layers > 0"
The commit-msg pre-commit hook validates every commit message against the conventional commits format and rejects non-conforming messages.
Bumping the version
Version bumps are driven by commitizen, wrapped in just recipes. Preview first with the -preview (dry-run) variant, then apply. Each apply recipe updates version in pyproject.toml, appends to CHANGELOG.md, and creates the bump commit and tag.
Goal |
Preview |
Apply |
|---|---|---|
Stable release |
|
|
Release candidate |
|
|
The next version is inferred from the conventional commits since the last tag. To force a level when it is not auto-detected, append the increment, e.g. just bump --increment MAJOR.
Changelog
CHANGELOG.md at the repository root is the authoritative changelog, updated automatically by the bump recipes. Changes are grouped under their commit types (feat, fix, perf, …) with the subject line of every matching commit since the previous release.