TirsvadandClaude Sonnet 5.5
4de5438a88
Adopt the SQA/QC framework as a submodule and plan the project before any further code: Business Case, Stakeholder Analysis (S01-S05), Project Plan with use case candidates and prioritisation, and milestones MIL-001..MIL-004 (24 tasks, synced to Gitea as milestones 18-21 and issues #1-#24). README now separates implemented from planned capabilities, has an English sequence diagram and points at the scoped workflow. The workflow file moves out of the repository root and out of .gitea/workflows/; the scoped copy is unchanged in behaviour here and still contains the known `exit 0` syntax error, which MIL-001 fixes. Refs #1 Refs #2 Refs #3 Refs #6 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2.8 KiB
2.8 KiB
MIL-004: Versioned release and publishing
Metadata
| Key | Value |
|---|---|
| ID | MIL-004 |
| CrossReference | BC-001 |
Version History
| Date | Status | Author | Reviewer | Change | Commit |
|---|---|---|---|---|---|
| 2026-10-03 | Proposed | Jens Tirsvad Nielsen | S01 | Initial version | pending |
| 2026-10-03 | Proposed | Jens Tirsvad Nielsen | S01 | Owner is S05 (security authority); S01 remains approving reviewer | pending |
Purpose
Decide whether workflow updates can be released with a version and adopted safely, and whether a project can publish an artifact through a shared workflow.
Deliverable
A documented release process for this repository (validation, version tag, changelog), a consumer upgrade guide and a reusable release workflow.
Go / No-Go Criteria
| # | Criterion (objectively checkable) | Go | No-Go |
|---|---|---|---|
| 1 | A release is validated by the MIL-001 checks before a tag is created | Enforced | Tag possible without checks |
| 2 | Each release has a version tag and a changelog entry that marks breaking changes | Present | Missing |
| 3 | A consumer pinned to the previous version keeps working after a release | Verified | Breaks |
| 4 | The publish destination (release page or package registry) is decided and its token scope documented | Decided | Open |
Dependencies
| Depends on | Reason |
|---|---|
| MIL-003 | Reuses the reusable workflow mechanism |
Traceability
| Business Case objective / KPI / user story | Reference |
|---|---|
| O4 | BC-001 |
Ownership
| Role | Stakeholder ID (SA) |
|---|---|
| Owner | S05 |
| Approving reviewer | S01 |
Target Date
2026-11-28 — proposed; to be confirmed by S01 and S05.
Tasks
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
|---|---|---|---|---|
| 1 | Define the release process for this repository | Describe how a workflow change is validated, tagged and announced, and how consumers pin a version. | Yes | Use case candidate: release a reusable workflow |
| 2 | Add a changelog and tag convention | Create CHANGELOG.md and a tag scheme (for example v1 plus v1.2.3) that separates breaking from compatible changes. |
No | |
| 3 | Write the consumer upgrade guide | Explain how to read a changelog entry, test an update in one repository and roll back. | Yes | Use case candidate: consume a workflow update |
| 4 | Decide the publish destination | Choose the release or package destination for built artifacts and document the token scope it needs. | No | |
| 5 | Implement the reusable release workflow | Validate the version, build release notes from the changelog and publish to the chosen destination. | Yes | Use case candidate: publish a release |