Skip to main content

上架流程

详细操作流程​

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

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

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

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

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

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

  1. 在 GitHub 或 Gitee 上创建公开仓库

  2. 创建 Release 并上传包资源

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

    具体步骤：

    • 进入仓库的「Releases」页面
    • 点击「Create a new release」（GitHub）或「新建发行版」（Gitee）
    • 标签版本：必须与 config.ini 中的 version 字段完全一致（格式：xx.yy.zzz）。前缀 v 可选但推荐使用（如 v1.0.0 或 1.0.0）
    • Release 标题：建议使用相同的版本号字符串（如 v1.0.0）
    • 附加二进制文件：按照以下命名规范将包文件上传为 Release 资源
重要

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

  1. 包资源命名与内容要求

    包文件必须遵循以下命名规范。版本号不包含在文件名中——版本通过 Release 标签指定。

包文件命名规范
应用类型所需资源格式命名规范内容要求
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 字段一致（双包模式）
重要
  • 版本号不包含在包文件名中。 版本通过 Release 标签指定。
  • Release 标签必须与 config.ini 中的 version 字段完全一致。 不一致将导致自动驳回。
  • 平台仅从 Release 中拉取包，而非仓库根目录。 不遵守将导致自动驳回。
  • 仅支持以上列出的格式和命名规范。 不符合规范的命名将导致自动驳回。

  1. 附带 SHA-256 校验和文件

    对于每个上传的包资源，生成并附加对应的 .sha256 校验和文件：

    sha256sum <包文件> > <包文件>.sha256

    示例：myapp_x86_64.deb → myapp_x86_64.deb.sha256

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

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

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

第五步：新增应用版本​

  1. 在【我的应用】中找到目标应用，点击【版本管理】
  2. 点击【新增版本】，填写版本号
    • 版本号格式：严格遵循 xx.yy.zzz（主版本号.次版本号.修订号）
    • 不可重复使用历史版本号
    • 必须与 config.ini 中的 version 字段一致
  3. 提交版本后进入上架申请流程
版本一致性要求

在第五步中填写的版本号必须与以下两项一致：

  1. config.ini 中的 version 字段
  2. 第三步中创建的 Release 标签版本

三者必须完全一致。 不一致将导致自动驳回。

第六步：平台自动校验​

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

  • 文件格式校验（config.ini JSON 语法、app.lang 格式）
  • 字段完整性校验（必填字段无缺失）
  • 语言覆盖校验（14 种语言节点全部存在）
  • 图标校验（SVG 格式、路径匹配）
  • 校验和验证（SHA-256 与上传文件匹配）
  • 版本一致性校验（config.ini / DEBIAN/control / app.lang 版本匹配。Docker 应用检查 config.ini 和 app.lang 的版本一致性，无需检查 DEBIAN/control。）
  • Release 标签与 config.ini.version 一致性校验

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

  • config.ini 包含注释或语法错误
  • app.lang 缺少语言节点
  • 图标未找到或格式错误
  • 校验和不匹配
  • Release 标签与 config.ini.version 不一致
  • 包文件名不符合命名规范

第七步：人工审核​

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

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

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

第八步：审核结果通知​

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

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

审核状态说明：

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

第九步：正式上架​

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

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

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

仓库要求​

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

应用更名和 ID 变更政策：

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