SOW 博客 on SOW

SOW v0.5.0

Vonng — Tue, 29 Sep 2026 00:00:00 +0800

SOW 0.5.0 主要解决已有平面 YUM 仓库接入 SOW 时的兼容问题。核心新增功能是 sow create --metadata-timestamp SECONDS：替换原有元数据生成器时，发布者可以保留合法的发布时间，兼容已有 EL7 YUM 客户端的缓存。

SOW v0.4.0

Vonng — Mon, 24 Aug 2026 00:00:00 +0000

SOW 0.4.0 是一次面向 Managed 仓库的完整性与恢复版本：它明确了深度校验的 I/O 契约，禁止跨无关密钥拼装 RPM 信任，提供可审计的发布目标可变配置修正路径，并补齐 v0.3 迁移与发布中断恢复的剩余缺口。

SOW v0.3.0

Vonng — Mon, 10 Aug 2026 00:00:00 +0000

SOW 0.3.0 围绕性能、持久性与产品边界完成了一次集中改进：Plain 仓库生成只需一遍包体处理； Managed 仓库消除了逐对象成员查询，复用经过认证的软件包事实，并用有界组提交提升载荷。正式交付的二进制与发布流水线也统一收敛到 SOW 实际支持的仓库工作流。

协同发布决策记录

Vonng — Fri, 14 Aug 2026 00:00:00 +0000

SOW 0.4.0 已完成最终决策

本记录的早期版本曾提议采用 rclone Executor、publish --dry-run 与独立 sow audit 命令。这些表面均未进入 0.4.0：SOW 不依赖 rclone，publish 没有 --dry-run，sow audit 也不是有效命令。

SOW v0.2.0

Vonng — Sat, 08 Aug 2026 00:00:00 +0000

SOW 0.2.0 是 Pigsty 出品的自包含 RPM/DEB 仓库管理器，Release 资产以单个 Go 可执行文件覆盖 Linux 与 macOS 构建目标。

两种工作模式

Plain 模式 给目录顶层已有的 RPM 与 DEB 文件就地生成索引：

SOW 设计演进：从 Route Graph 收敛到 Repository Core

Vonng — Mon, 10 Aug 2026 00:00:00 +0000

本文对应 2026-08-10 围绕 Repository Core 完成的 SOW 收敛决策。它从早期规划、ADR、评审、迁移与验证目录中提炼值得维护的结论，但不会把每份过程制品都变成另一套产品文档。

发布与恢复

Vonng — Sat, 08 Aug 2026 00:00:00 +0000

构建与发布是两个独立状态迁移。构建产生与 target 无关的 Generation；发布把该 Generation 应用到一个供应商前缀，并记录足以在不猜测的前提下恢复的证据。

所有权拆分

Repository 作用域	Target prefix 作用域
Package Object	Publication Attempt
Desired 与 Built 状态	Applied Checkpoint
Generation 与 Changeset	远端 inventory
retained 包体/元数据引用	grace 与删除证据

这项拆分避免把 filesystem 发布成功当成 R2 的证据，也避免一个 target 的半完成尝试污染另一个。

系统模型

Vonng — Sat, 08 Aug 2026 00:00:00 +0000

SOW 刻意把模型分层：配置表达意图，数据库记录有主状态，公共树是确定性投影。任何一层都不能悄悄替代另一层。

对象层级

Workspace
├── Repository
│   ├── Package Object
│   ├── Dist
│   │   └── Membership -> Package Object
│   ├── Desired 状态
│   ├── Built Generation
│   └── Retained Generation 引用
└── Publication Target
    └── Repository + provider + prefix

Workspace

Workspace 提供发现、配置与协调，拥有 sow.yml、私有 .sow/ 目录和稳定锁路径；它不是包体去重域。

设计原则

Vonng — Sat, 08 Aug 2026 00:00:00 +0000

SOW 首先不是一个“元数据生成器”，而是一个所有权与状态迁移系统，只是它的输出恰好是 APT 与 RPM 仓库。下面这些原则让整套系统保持可推理。

每个持久事实只有一个主人

每类持久事实都只有一个作用域与权威：

为什么 SOW 每个仓库只保留一棵包体树

Vonng — Wed, 05 Aug 2026 00:00:00 +0000

这项决策起草于 2026-08-05 的 v0.2 发布前设计收敛阶段，并在 2026-08-08 随 SOW v0.2.0 正式交付，随后延续为 v0.3 与 v0.4 的布局契约。它记录的是架构选择，不是笼统的兼容性 PASS：协议闭包、普通软件包客户端、镜像工具、静态托管与对象存储始终属于彼此独立的证据层。

v0.2 重置：用 Plain 与 Managed 取代万能控制面

Vonng — Fri, 31 Jul 2026 00:00:00 +0000

开发设计线不等于发布版本

归档中的“v0.2”设计线最初使用 C2 View-local RPM Hardlink。这是一条真实实现过的开发线，但在最终 v0.2.0 Tag 之前已经被单包体设计替换。正式发布的 v0.2.0 已经使用唯一正典 Pool 与纯元数据 View。

SOW v0.1 到底证明了什么

Vonng — Fri, 31 Jul 2026 00:00:00 +0000

版本绑定的证据

本页每项结果都只属于当时记录的 v0.1 源码、布局、Fixture 与环境，不能证明当前 SOW 的兼容性或发布就绪。

v0.1 归档包含 112 份日期化 Evidence Report，覆盖 2026-07-11 至 2026-07-31。把它们全部发布成博客只会降低公共站点的可用性：其中很多是窄故障闭包、重复的 Current-source Audit，或某个具体实现 Seam 的执行记录。

SOW v0.1 决策账本：哪些被保留，哪些已退役

Vonng — Sun, 12 Jul 2026 00:00:00 +0000

历史决策账本

v0.1.0 Tag 中现存 44 份 ADR，编号从 0001 到 0045，其中缺少 0006。本文保留它们的意义，但不会把每份历史实现契约重新发布成当前指南。

即使实现已经退役，ADR 仍有价值：它记录团队拒绝忽略的失败模式、当时选择的边界，以及危险操作进入执行前必须取得的证据。

SOW v0.1 原始计划：软件仓库的 Git

Vonng — Sat, 11 Jul 2026 00:00:00 +0000

历史设计记录

本文描述 2026-07-11 启动、并在 2026-07-31 封存为 v0.1.0 源码基线的原始计划。 Git/CAS/Route/Edge 产品模型已经退役；当前行为以 SOW 文档和维护中的系统模型为准。

SOW 最初并不是一个小型仓库索引器。原始目标是用一个 Go 控制面，替换 Pigsty 中庞大的 Makefile + rclone 工作流，统一管理 APT、YUM 与静态制品，覆盖本地状态、包生命周期、上游同步、Channel、View、Snapshot、双云发布、CDN 行为、商业访问控制、迁移、恢复与验证。