Document development workflow
This commit is contained in:
@@ -0,0 +1,55 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user