-
SOW v0.5.0
SOW 0.5.0 为已有 YUM 仓库增加发布时间参数，并修复 Managed 仓库的恢复、签名和包路径处理。 构建过程也减少了对未变化软件包的重复校验。 安装方式见下载 SOW。使用 0.3 或 0.4 Managed 工作区时，先迁移各个 Repository，再进行写操作。 升级 Managed 工作区 停止向工作区写入的命令。 备份完整工作区，包括 sow.yml、.sow/ 和所有 Repository 根目录。 安装 SOW 0.5.0。 逐个迁移、构建并检查 …
SOW 0.5.0 为已有 YUM 仓库增加发布时间参数，并修复 Managed 仓库的恢复、签名和包路径处理。 构建过程也减少了对未变化软件包的重复校验。 安装方式见下载 SOW。使用 0.3 或 0.4 Managed 工作区时，先迁移各个 Repository，再进行写操作。 升级 Managed 工作区 停止向工作区写入的命令。 备份完整工作区，包括 sow.yml、.sow/ 和所有 Repository 根目录。 安装 SOW 0.5.0。 逐个迁移、构建并检查 …
-
SOW v0.4.0
SOW 0.4.0 改进了 Managed 仓库的校验与恢复。check 只对每个物理软件包计算一次内容哈希；RPM 验签分别判断各组密钥的信任结果；发布目标可通过有记录的重绑定操作修改公共 URL 或缓存时间。 Plain 行为与公共 pool/、dists/ 布局保持不变。本文记录 0.4.0；升级到当前版本请按安装指南操作。 从 0.3 升级到 0.4 停止工作区写入，备份完整工作区并保留硬链接。安装 0.4.0 后，先迁移每个已配置的 Repository，再继续维护： set -euo …
SOW 0.4.0 改进了 Managed 仓库的校验与恢复。check 只对每个物理软件包计算一次内容哈希；RPM 验签分别判断各组密钥的信任结果；发布目标可通过有记录的重绑定操作修改公共 URL 或缓存时间。 Plain 行为与公共 pool/、dists/ 布局保持不变。本文记录 0.4.0；升级到当前版本请按安装指南操作。 从 0.3 升级到 0.4 停止工作区写入，备份完整工作区并保留硬链接。安装 0.4.0 后，先迁移每个已配置的 Repository，再继续维护： set -euo …
-
协同发布决策记录
SOW 0.4.0 保留了原生 filesystem 与 r2 发布后端。早期提案曾计划使用 rclone，并增加远端审计和预览命令。 最终选择原生后端，是因为 SOW 需要逐项记录条件写入及其结果。 当前命令语法见 sow publish。 为什么保留原生后端 发布计划为每个文件记录预期 SHA-256 和操作。后端需要创建不可变对象，避免覆盖已有内容，并按条件更新可变入口文件。 SOW 记录操作结果，用于中断后继续发布。 批量复制工具需要额外的身份与检查点模型才能保留这些规则。0.4 选择 …
SOW 0.4.0 保留了原生 filesystem 与 r2 发布后端。早期提案曾计划使用 rclone，并增加远端审计和预览命令。 最终选择原生后端，是因为 SOW 需要逐项记录条件写入及其结果。 当前命令语法见 sow publish。 为什么保留原生后端 发布计划为每个文件记录预期 SHA-256 和操作。后端需要创建不可变对象，避免覆盖已有内容，并按条件更新可变入口文件。 SOW 记录操作结果，用于中断后继续发布。 批量复制工具需要额外的身份与检查点模型才能保留这些规则。0.4 选择 …
-
SOW 设计演进：从路由图到仓库引擎
SOW 在 v0.1 中探索了以 Git 为核心的软件分发控制面，在 v0.2 中转为仓库引擎。 本文记录这次变化，以及后续到 v0.5.0 的改进。 下文版本号指正式 Git 标签。部分归档计划曾用“v0.2”“v0.3”指代开发中的设计； 其中在 RPM 视图内创建硬链接的 C2 布局，已在 v0.2.0 发布前被替换。 早期工作的细节见四篇配套文章： v0.1 原始产品计划说明最初的范围，以及范围为何过大。 v0.1 决策账本记录现存的 44 份 ADR 及其后续变化。 v0.1 到底证明 …
SOW 在 v0.1 中探索了以 Git 为核心的软件分发控制面，在 v0.2 中转为仓库引擎。 本文记录这次变化，以及后续到 v0.5.0 的改进。 下文版本号指正式 Git 标签。部分归档计划曾用“v0.2”“v0.3”指代开发中的设计； 其中在 RPM 视图内创建硬链接的 C2 布局，已在 v0.2.0 发布前被替换。 早期工作的细节见四篇配套文章： v0.1 原始产品计划说明最初的范围，以及范围为何过大。 v0.1 决策账本记录现存的 44 份 ADR 及其后续变化。 v0.1 到底证明 …
-
SOW v0.3.0
SOW 0.3.0 减少了重复包读取与数据库查询。Plain 生成只遍历一次包内容；Managed 构建缓存已解析的包数据，并批量提交新包池文件。本版还移除了已退役的运行时与发布代码。 Plain：每个软件包只读一次 默认不签名的 sow create 流程对每个 RPM 或 DEB 只做一次哈希与解析，--jobs 控制并行任务数。SOW 根据解析结果生成元数据，写入索引前再次检查软件包集合与文件属性是否变化。 Plain 构建中断后，从软件包目录重新运行即可。0.3 移除了 Plain 的操 …
SOW 0.3.0 减少了重复包读取与数据库查询。Plain 生成只遍历一次包内容；Managed 构建缓存已解析的包数据，并批量提交新包池文件。本版还移除了已退役的运行时与发布代码。 Plain：每个软件包只读一次 默认不签名的 sow create 流程对每个 RPM 或 DEB 只做一次哈希与解析，--jobs 控制并行任务数。SOW 根据解析结果生成元数据，写入索引前再次检查软件包集合与文件属性是否变化。 Plain 构建中断后，从软件包目录重新运行即可。0.3 移除了 Plain 的操 …
-
设计原则
SOW 分别管理包存储、仓库构建和发布。以下原则说明各类状态由谁保存，以及操作如何使用这些状态。 每类记录由一个对象管理 记录 管理范围 包体与包身份 Repository Desired 成员关系与 Built 状态 Repository Generation 与变更集 Repository 目标绑定与修订记录 Repository 与发布目标 发布尝试与检查点 Repository 与目标前缀 远端清单与删除记录 Repository 与目标前缀 每个 Repository 分别保存自己的包 …
SOW 分别管理包存储、仓库构建和发布。以下原则说明各类状态由谁保存，以及操作如何使用这些状态。 每类记录由一个对象管理 记录 管理范围 包体与包身份 Repository Desired 成员关系与 Built 状态 Repository Generation 与变更集 Repository 目标绑定与修订记录 Repository 与发布目标 发布尝试与检查点 Repository 与目标前缀 远端清单与删除记录 Repository 与目标前缀 每个 Repository 分别保存自己的包 …
-
系统模型
SOW 用配置文件保存仓库设置，用 SQLite 记录托管状态，用公共目录向客户端提供文件。 模型分别记录选中的软件包、已完成的构建，以及已发布的内容。 对象 Workspace（工作区） ├── Repository（仓库） │ ├── Pool：包对象 │ ├── Dist：成员关系与策略 │ ├── Desired（期望状态） │ ├── Built Generation（已构建快照） │ └── 保留的 Generation └── 发布目标 └── Repository + 存储后端 …
SOW 用配置文件保存仓库设置，用 SQLite 记录托管状态，用公共目录向客户端提供文件。 模型分别记录选中的软件包、已完成的构建，以及已发布的内容。 对象 Workspace（工作区） ├── Repository（仓库） │ ├── Pool：包对象 │ ├── Dist：成员关系与策略 │ ├── Desired（期望状态） │ ├── Built Generation（已构建快照） │ └── 保留的 Generation └── 发布目标 └── Repository + 存储后端 …
-
发布与恢复
构建生成本地快照（Generation）。发布把快照中的文件上传到目标，并记录进度，以便中断后继续。 每个目标分别保存检查点，记录上次完成发布的内容。 状态归属 Repository 记录 目标记录 软件包、Desired 状态与 Built 状态 发布尝试与检查点 Generation 与变更集 远端清单 保留的包和元数据引用 宽限期与删除记录 发布顺序 固定发布计划 -> 上传包体 -> 上传不可变元数据 -> 记录提交意图 -> 按视图逐一更新协议入口文件 -> 校验存储与公共 URL …
构建生成本地快照（Generation）。发布把快照中的文件上传到目标，并记录进度，以便中断后继续。 每个目标分别保存检查点，记录上次完成发布的内容。 状态归属 Repository 记录 目标记录 软件包、Desired 状态与 Built 状态 发布尝试与检查点 Generation 与变更集 远端清单 保留的包和元数据引用 宽限期与删除记录 发布顺序 固定发布计划 -> 上传包体 -> 上传不可变元数据 -> 记录提交意图 -> 按视图逐一更新协议入口文件 -> 校验存储与公共 URL …
-
SOW v0.2.0
SOW 0.2.0 引入了面向 RPM 与 DEB 仓库的 Plain 和 Managed 工作流。它以单个 Go 可执行文件，在 Linux 或 macOS 上构建静态软件包仓库。 本文记录 0.2.0 发布时的功能。当前安装与操作方法见现行文档。 构建平面仓库 Plain 模式索引目录顶层的 RPM 与 DEB 文件： sow create /srv/repo RPM 生成 repodata/，DEB 生成 Packages 与 Packages.gz，混合目录同时生成两种索引。Plain …
SOW 0.2.0 引入了面向 RPM 与 DEB 仓库的 Plain 和 Managed 工作流。它以单个 Go 可执行文件，在 Linux 或 macOS 上构建静态软件包仓库。 本文记录 0.2.0 发布时的功能。当前安装与操作方法见现行文档。 构建平面仓库 Plain 模式索引目录顶层的 RPM 与 DEB 文件： sow create /srv/repo RPM 生成 repodata/，DEB 生成 Packages 与 Packages.gz，混合目录同时生成两种索引。Plain …
-
为什么 SOW 每个仓库只保留一棵包体树
这项决策起草于 2026-08-05，随 2026-08-08 的 SOW v0.2.0 发布。SOW 0.5.0 仍使用这一布局： 每个仓库保存一棵包体树，各发行版视图引用同一棵树。 决策 每个 Repository 的公共目录如下： <repository>/ pool/ # 包体 dists/ <dist>/ <architecture>/ # RPM 元数据 上图展示 RPM 视图。APT 索引位于 dists/<dist>/main/binary-<architecture>/， …
这项决策起草于 2026-08-05，随 2026-08-08 的 SOW v0.2.0 发布。SOW 0.5.0 仍使用这一布局： 每个仓库保存一棵包体树，各发行版视图引用同一棵树。 决策 每个 Repository 的公共目录如下： <repository>/ pool/ # 包体 dists/ <dist>/ <architecture>/ # RPM 元数据 上图展示 RPM 视图。APT 索引位于 dists/<dist>/main/binary-<architecture>/， …
-
SOW v0.1 到底证明了什么
v0.1 归档包含 112 份报告，日期从 2026-07-11 到 7 月 31 日。 它们记录了客户端测试、规模测量、故障恢复、迁移和云存储实验。 本文汇总主要结果，并链接到代表性报告。 每项结果对应报告中记录的源码版本、测试数据、客户端与环境。 当前支持情况见兼容性参考。 证据时间线 时间 报告数 主要工作 2026-07-11 3 真实 APT/DNF 基线、72,310 个包的清单扫描、5 万个上游包的流式处理 2026-07-12 35 APT/YUM 协议、CAS/GC、发布顺序、 …
v0.1 归档包含 112 份报告，日期从 2026-07-11 到 7 月 31 日。 它们记录了客户端测试、规模测量、故障恢复、迁移和云存储实验。 本文汇总主要结果，并链接到代表性报告。 每项结果对应报告中记录的源码版本、测试数据、客户端与环境。 当前支持情况见兼容性参考。 证据时间线 时间 报告数 主要工作 2026-07-11 3 真实 APT/DNF 基线、72,310 个包的清单扫描、5 万个上游包的流式处理 2026-07-12 35 APT/YUM 协议、CAS/GC、发布顺序、 …
-
v0.2 重置：用 Plain 与 Managed 取代万能控制面
2026-07-31，v0.1 源码基线封存后，SOW 开始了一次产品重置。 目标是构建一个小型仓库引擎，替代 Pigsty 日常软件包构建工作流。 重置保留了已有的完整性与恢复经验，同时移除了大部分控制面。 最终形成的分工沿用至今：Plain 重建调用者拥有的目录，Managed 管理仓库及其历史。 开发设计最初在 RPM 视图内使用 C2 硬链接，随后在 8 月 8 日发布 v0.2.0 前被替换。 部分归档计划曾把 C2 构建称为“v0.2.0”，但正式标签已经采用单一包池与纯元数据视图。 …
2026-07-31，v0.1 源码基线封存后，SOW 开始了一次产品重置。 目标是构建一个小型仓库引擎，替代 Pigsty 日常软件包构建工作流。 重置保留了已有的完整性与恢复经验，同时移除了大部分控制面。 最终形成的分工沿用至今：Plain 重建调用者拥有的目录，Managed 管理仓库及其历史。 开发设计最初在 RPM 视图内使用 C2 硬链接，随后在 8 月 8 日发布 v0.2.0 前被替换。 部分归档计划曾把 C2 构建称为“v0.2.0”，但正式标签已经采用单一包池与纯元数据视图。 …
-
SOW v0.1 决策账本：哪些被保留，哪些已退役
v0.1.0 标签中有 44 份架构决策记录（ADR），编号为 0001 至 0045，缺少 0006。 每份 ADR 记录一个问题、当时的决策及实现必须满足的条件。 下表说明仓库模型变化后，各项决策的后续情况。 状态 含义 保留 原则以基本相同的范围继续用于当前 SOW。 演化 问题仍在，但所有权或实现已经改变。 迁移历史 决策用于 Pigsty/V1 切换。 退役 决策属于已移除的 Git/CAS/Route/Edge 模型。 决策日期从 2026-07-11 到 7 月 28 日 …
v0.1.0 标签中有 44 份架构决策记录（ADR），编号为 0001 至 0045，缺少 0006。 每份 ADR 记录一个问题、当时的决策及实现必须满足的条件。 下表说明仓库模型变化后，各项决策的后续情况。 状态 含义 保留 原则以基本相同的范围继续用于当前 SOW。 演化 问题仍在，但所有权或实现已经改变。 迁移历史 决策用于 Pigsty/V1 切换。 退役 决策属于已移除的 Git/CAS/Route/Edge 模型。 决策日期从 2026-07-11 到 7 月 28 日 …
-
SOW v0.1 原始计划：软件仓库的 Git
v0.1 计划始于 2026-07-11，并于 7 月 31 日封存为 v0.1.0。 它计划用一个 Go 控制面替换 Pigsty 的 Makefile 与 rclone 工作流，统一管理 APT、YUM 和静态制品。 范围包括本地状态、包历史、上游同步、渠道、视图、快照、双云发布、CDN 行为、商业访问控制和迁移。 当时的核心说法是：“制品仓库的 Git”。 软件分发确实需要不可变内容、可变名称、历史、晋级、 发布与回滚。这个类比帮助描述了需求，也扩大了产品范围。 …
v0.1 计划始于 2026-07-11，并于 7 月 31 日封存为 v0.1.0。 它计划用一个 Go 控制面替换 Pigsty 的 Makefile 与 rclone 工作流，统一管理 APT、YUM 和静态制品。 范围包括本地状态、包历史、上游同步、渠道、视图、快照、双云发布、CDN 行为、商业访问控制和迁移。 当时的核心说法是：“制品仓库的 Git”。 软件分发确实需要不可变内容、可变名称、历史、晋级、 发布与回滚。这个类比帮助描述了需求，也扩大了产品范围。 …