56 lines
1.3 KiB
Markdown
56 lines
1.3 KiB
Markdown
# ADR 0010: Development Workflow
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
The project is expected to evolve over an extended period and will be developed with the assistance of AI coding tools.
|
|
|
|
To maintain code quality, architectural consistency and a comprehensible project history, a common development workflow is required.
|
|
|
|
## Decision
|
|
|
|
The project follows a feature-branch based development workflow.
|
|
|
|
The `main` branch shall always represent a stable and working state.
|
|
|
|
Development of new functionality shall take place on dedicated feature branches.
|
|
|
|
Examples:
|
|
|
|
- feature/domain-model
|
|
- feature/storage
|
|
- feature/import
|
|
- feature/transcription
|
|
- feature/diarization
|
|
- feature/export
|
|
- feature/ui
|
|
|
|
Feature branches shall be merged into `main` only after:
|
|
|
|
- implementation is complete
|
|
- documentation has been updated where required
|
|
- all tests pass
|
|
- static analysis completes without errors
|
|
|
|
Architectural changes shall be documented using Architecture Decision Records (ADRs).
|
|
|
|
Project versioning follows Semantic Versioning.
|
|
|
|
Version numbers shall be maintained in:
|
|
|
|
- `pyproject.toml`
|
|
- `CHANGELOG.md`
|
|
|
|
Each released version shall be tagged in Git.
|
|
|
|
|
|
## Consequences
|
|
|
|
- Development history remains easy to understand.
|
|
- Experimental work is isolated from the stable branch.
|
|
- Architectural decisions remain documented.
|
|
- Releases are reproducible through Git tags.
|