Version: TOS 7

上架流程

详细操作流程

第一步：注册开发者账号

访问 TOS 开发者平台：https://developer.terra-master.com
点击【注册】按钮，进入注册信息填写页面
使用有效电子邮箱作为登录账号，填写开发者姓名（建议与配置文件中的 publisher 字段保持一致）
阅读并同意服务协议，点击【确定】完成注册
注册后需完成邮箱验证，账号即时生效，无需人工审核。

注意

账号邮箱用于接收审核结果通知、密码重置等重要信息，请保持邮箱有效。

第二步：获取配置模板与开发应用

参考本文档第 8 章（Deb 应用开发与配置规范）中的标准模板编写 config.ini、app.lang、systemd 服务文件等配置，或使用 TOS 开发者平台推荐的项目模板仓库快速初始化
按照本文档规范完成应用开发与封装
本地测试验证（参见第 13 章）

第三步：创建 Release 并上传包资源

在 GitHub 或 Gitee 上创建公开仓库
创建 Release 并上传包资源

平台仅从 Release（GitHub Releases 或 Gitee Releases）中拉取应用包。请勿将包文件直接上传至仓库根目录。

具体步骤：
- 进入仓库的「Releases」页面
- 点击「Create a new release」（GitHub）或「新建发行版」（Gitee）
- 标签版本：任意标签均可。建议按版本号命名（如 v1.0.0 或 1.0.0）以便阅读，但不要求与 config.ini.version 一致。提交版本时你会选择该标签
- Release 标题：建议使用相同的版本号字符串（如 v1.0.0）
- 附加二进制文件：按照以下命名规范将包文件上传为 Release 资源

重要

平台仅从 Release中拉取应用包，请勿将包文件直接上传至仓库根目录。

包资源命名与内容要求

按下表命名包文件。平台通过文件扩展名识别包类型（.deb = 单包，.tar.gz = 双包归档或 Docker 包）。版本从 config.ini 读取，因此无需出现在文件名中。平台不校验文件名本身 —— 下表推荐名称只是便于你在提交时挑选正确的资源。包的身份在下载解析后，以 config.ini 与你在开发者平台填写的信息比对确认。

包文件命名规范

应用类型	所需资源格式	命名规范	内容要求
Deb（单包模式）	`.deb` 文件	`<app_id>_<platform>.deb`	包含所有应用文件、配置和元数据的单个 deb 包
Deb（双包模式）	`.tar.gz` 压缩包	`<app_id>_<platform>.tar.gz`	必须包含 `<app_id>.deb`（数据包）和 `<package>.deb`（源包）
Docker 应用	`.tar.gz` 压缩包	`<app_id>.tar.gz`	必须包含 `docker-compose.yml`、`config.ini`、`app.lang` 和图标文件

字段定义：

<app_id>：建议与 config.ini 中的 id 字段一致
<platform>：建议与 config.ini 中的 platform 字段一致，且为两个受支持值之一（x86_64 或 aarch64）。多架构需分别构建提交；平台不从文件名读取架构
<package>：应与 config.ini 中的 package 字段一致（双包模式）

重要

版本从 config.ini 的 version 字段读取。 无需出现在文件名中，也无需出现在 Release 标签中。
平台仅从 Release 中拉取包，而非仓库根目录。
同一个 GitHub/Gitee Release 中可以上传多个包（例如不同架构）。提交版本时，平台会列出该仓库 Releases 中的所有包，由你选择要提交的那一个。
务必确认所选包与创建应用时声明的应用类型和架构一致。 例如，不要为声明为 x86_64 的应用提交 aarch64 包。
同一应用 ID 不要在同一 Release 中混用打包格式（如同时放 .deb 和 .tar.gz）。平台靠文件扩展名区分单包 Deb（.deb）与双包 Deb / Docker（.tar.gz），因此一个 Release 应只放一种格式。
选择正确的包由你负责。 提交错误的包会导致该版本审核不通过。

附带 SHA-256 校验和文件

对于每个上传的包资源，生成并附加对应的 .sha256 校验和文件：
```
sha256sum <包文件> > <包文件>.sha256
```
示例：myapp_x86_64.deb → myapp_x86_64.deb.sha256

每个上传的包资源必须附带对应的 .sha256 校验和文件。

第四步：在开发者平台创建应用

登录开发者平台，点击【我的应用】→【新增应用】
填写应用信息 —— 仅需四个字段：
- 应用 ID：与 config.ini 中的 id 字段完全一致
- 应用包类型：选择 Deb 或 Docker
- 架构：选择 x86_64 或 aarch64
- 仓库地址：填写公开仓库地址（必须公开，否则审核无法进行）
确认无误后提交创建

注意

先创建应用，再提交版本。创建时无需填写版本号 —— 平台从你下一步选择的包中获取版本。包下载解析后，平台将 config.ini 中的应用信息（id、platform、包类型）与这里填写的信息比对，一致才继续。

第五步：新增应用版本

在【我的应用】中找到目标应用，点击【版本管理】
点击【新增版本】。平台调用仓库接口，返回该应用所配置仓库地址的 Releases 中全部可安装的包
选择要提交的 Release（标签）和包文件
- 不要手动填写版本号 —— 版本从所选包内的 version 字段读取
- 重复或更低的版本号不再被拒绝，但应用中心按版本号数值比较来判断更新 —— 不大于已安装版本的包不会作为更新推送给存量用户
- Release 及其资源必须保持可用，因为平台会在审核时从所选 Release 下载包
提交版本后进入上架申请流程

版本来源与一致性：

版本来自包本身，始终取 config.ini 中的 version 字段。没有手动填写的版本号，Release 标签也不必与版本一致。

平台不校验版本号 —— 不校验格式、不校验递增、也不校验是否与 DEBIAN/control 一致。但请注意，应用中心按版本号数值比较来判断更新，因此不大于已安装版本的版本不会作为更新推送给存量用户。

第六步：平台自动校验

提交后平台自动执行以下检查：

文件格式校验（config.ini JSON 语法、app.lang 格式）
字段完整性校验（必填字段无缺失）
语言覆盖校验（14 种语言节点全部存在）
图标校验（SVG 格式、路径匹配）
校验和验证（SHA-256 与上传文件匹配）
包类型校验（所选包的格式与声明的 Deb / Docker 应用类型一致）

自动校验失败的常见原因：

config.ini 包含注释或语法错误
app.lang 缺少语言节点
图标未找到或格式错误
校验和不匹配
所选包与声明的应用类型或架构不一致

第七步：人工审核

审核团队从四个维度进行审核（详见第 16 章）：

配置完整性（权重 30%）：所有必需文件齐全，格式正确
功能可用性（权重 35%）：安装、启动、运行、卸载完整无异常
安全性（权重 25%）：无恶意代码、无过度授权、无敏感硬编码
合规性（权重 10%）：内容合规，描述与功能一致

审核流程：初审（信息一致性、仓库规范性）→ 安全性审核（技术支持人员）→ 功能兼容性测试（测试支持人员）→ 综合审核（专职审核人员）

第八步：审核结果通知

审核结果通过两种渠道通知开发者：

平台消息：登录开发者平台可查看审核状态
注册邮箱：审核结果发送至注册时使用的邮箱

审核状态说明：

审核中：应用正在审核队列中
审核通过：应用已通过审核，进入上架流程
审核驳回：应用存在问题需整改，需在 30 天内修正并重新提交
自主撤回：开发者主动撤回审核申请

第九步：正式上架

审核通过后，应用将在 1-2 个工作日内上线至 TOS 应用中心：

用户可在应用中心搜索并安装应用
开发者可在【我的应用】中查看应用状态变更为"已上架"

统计信息： 开发者主页展示已发布应用数、应用总下载量、累计提交应用数等核心数据。最近 3 条上架申请进展情况实时更新。

仓库要求

必须为 公开仓库（GitHub 或 Gitee）。私有仓库不予支持。
包文件必须作为 Release 资源上传，不得上传至仓库根目录。
仓库资源需长期保持可用。不可删除已上架的资源。
仓库结构必须符合指定的目录布局。
所有二进制产物需附带 SHA-256 校验和文件。

应用更名和 ID 变更政策：

应用 id（config.ini 中）一旦发布不可更改
应用展示名称（app.lang 中）可在新版本中更新
如需更改应用 id，必须作为全新应用提交（新上架、新审核）
旧应用必须走应用下架流程（参见 17.4 节）

详细操作流程​

第一步：注册开发者账号​

第二步：获取配置模板与开发应用​

第三步：创建 Release 并上传包资源​

第四步：在开发者平台创建应用​

第五步：新增应用版本​

第六步：平台自动校验​

第七步：人工审核​

第八步：审核结果通知​

第九步：正式上架​

仓库要求​