eric/notarius
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Align architecture and source release policies

Browse Source
This commit is contained in:
Eric Rakestraw
2026-09-28 01:35:01 +00:00
parent 21c07d4ef0
commit d4feccc456
5 changed files with 86 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
docs/policy/release.md
View File

@@ -1,11 +1,10 @@
# Release Policy
**Base Policy Version:** 1.1
**Base Policy Version:** 1.4
**Last Updated**: 2026-09-26
**Last Updated**: 2026-09-28
Notarius adaptations: source-only delivery, lightweight tags, branch-before-tag
publication, no prereleases, and the justified native command check below.
**Upstream Source**: https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/release.md
## Purpose
@@ -72,22 +71,26 @@ source tree. Use the complete version tag as the filename and begin with a
title containing the product name and that exact version.
Include a short summary and any relevant compatibility impact or upgrade
instructions. Keep the note proportionate to the change. Fixed sections and
explicit no-action boilerplate are not required. Existing historical notes
need not be rewritten to adopt this format.
instructions. Choose sections suited to the release and keep the note
proportionate to the change.
Keep exact current contracts in their canonical documents and update affected
documentation with the behavior change. Link to those documents from the note
where useful. A release note must not substitute for current documentation.
where useful.
Include the release footer defined by the [OSS policy](oss.md#discoverability)
in each new release document. The [release procedure](../release.md) defines
its concrete immutable-tag URLs. Notarius has no hosted download page; preparing
these links with the note does not add a network check or approval gate.
Do not create retrospective notes for the pre-procedure v0.1.0, v0.2.0, or
v0.3.0 tags.
Version selection, release-note content, and retirement of completed roadmaps
are preparation responsibilities, not separate human approval gates. Preserve
planned and deferred work and repair affected links when retiring roadmaps.
Ordinary change review covers unintended files, credentials, and private data;
do not repeat it as a release-specific sign-off. Ignored local files are not
prohibited merely because they exist: they are not included in the tagged source.
Handle version selection, release-note content, and retirement of completed
roadmaps during preparation. Preserve planned and deferred work and repair
affected links when retiring roadmaps. Reuse ordinary change review for
unintended files, credentials, and private data. Scope release-content review
to the tagged source.
## Candidate Validation
@@ -191,9 +194,8 @@ identify:
1. prerequisites, primary branch, and authoritative remote;
2. version and release-note preparation;
3. one publication command with its selected local checks and automated guards;
4. declared deliverables, required build targets, and automation responsibilities;
5. the successful-push completion point and separately reported delivery status;
and
4. source-only delivery, required build targets, and automation responsibilities;
5. the successful-push completion point; and
6. failure handling and ambiguous-push recovery.
Use copyable commands where practical. Keep optional diagnostics and consumer