Aspects intended to be integrated but not yet designed:
- version the spec
- create a changelog
- list contributors
- Terminology/Glossary Section
- clear definitions of all technical terms used
- standardization of language throughout the spec
- abbreviations explained
- scope delineation
- clear boundaries of what DPM does and doesn’t do
- integration points with other systems
- expected deployment scenarios
- non-goals explicitly stated
- create a dedicated database recovery options section just for that
- need a section for package creation reference
Add’l Sections Needed
- System Boundaries & Integration Architecture
- should define completion relationship between DPM and DON
- how do they communicate
- what happens if don fails
- Build System Integration
- how do build systems create dpm packages
- what’s the interface between build system output and package creation
- package validation requirements at build time
- repository infrastructure
- repository metadata requirements
- repository sync mechanisms
- repository integrity verification
- repository chaining/fallback behaviour
- architectural principals and constraints
- why transactional?
- why build system agnostic?
- why separate hooks, contents, metadata, signatures?
- format evolution
- how will package format versions be handled?
- how will database schema changes be managed?
- backwards compatibility requirements
- migration paths
- how to handle existing packages during format changes
- how to handle database upgrades
- how to handle hook system changes
- how to handle signature system changes