From 6457e4e777283a5bf5e420464d9b09b6ed0c3487 Mon Sep 17 00:00:00 2001 From: Ryan Wang Date: Mon, 7 Sep 2026 10:42:35 +0800 Subject: [PATCH] Clarify review requirements for forked applications --- .../app-store/app-review-guidelines.md | 43 +++++++++++++++++-- 1 file changed, 40 insertions(+), 3 deletions(-) diff --git a/docs/developer-guide/app-store/app-review-guidelines.md b/docs/developer-guide/app-store/app-review-guidelines.md index 9d9bba89..80b80267 100644 --- a/docs/developer-guide/app-store/app-review-guidelines.md +++ b/docs/developer-guide/app-store/app-review-guidelines.md @@ -3,9 +3,9 @@ title: 应用市场审核指南 description: Halo 应用市场插件与主题上架审核规则及提交前自查清单，涵盖安全、性能、商业模式、设计、隐私与知识产权，以及常见拒绝、整改和申诉要求 --- -> 版本：`review-guidelines-v2026.06.25` +> 版本：`review-guidelines-v2026.09.07` > -> 生效日期：2026-06-25 +> 生效日期：2026-09-07 > > 运营主体：凌霞（深圳）软件有限公司 @@ -34,6 +34,7 @@ description: Halo 应用市场插件与主题上架审核规则及提交前自 - 涉及用户数据、站点内容、订单、许可证、日志或第三方服务时，已提供清晰说明 - 已按免费应用提交；如依赖第三方付费服务、外部授权或功能限制，已准确披露 - 开源许可证、第三方资源、商标、图片、字体、图标和模板授权清晰 +- 如应用基于已有插件或主题派生，已披露上游来源，并提供上游贡献记录、实质差异说明和持续维护计划；以接续维护为由申请上架的，还需提供上游明确停止维护的证据 - 支持链接可访问，且你能响应审核反馈、用户反馈和安全问题 - 已理解提交后平台会保存审核快照；审核期间如需修改应用、版本、说明或制品，应取消审核、等待驳回后重新提交，或按审核意见处理 @@ -154,9 +155,45 @@ description: Halo 应用市场插件与主题上架审核规则及提交前自 应用必须具备足够的实用功能。以下情况**将被拒绝**： - 功能过于简单，无法作为独立应用提供价值 -- 是已有应用的简单复制，或与当前应用市场已上架应用功能高度重合，未提供差异化功能、体验改进或新的使用场景 +- 是已有应用的简单复制，或与当前应用市场已上架应用功能高度重合，未提供差异化功能、体验改进或新的使用场景，且不符合 4.2.2 的接续维护要求 - 主要功能依赖外部网页或第三方应用，自身仅作为容器或跳转入口 +#### 4.2.1 Fork 与派生应用 + +应用市场优先收录具有独立使用价值、能够持续维护的应用，避免同类应用的轻微变体增加用户的辨别和选择成本。基于已有插件或主题进行 Fork、复制代码或二次开发的应用，均适用本条款，不以仓库是否保留 Fork 标记为判断依据。使用 AI 改写、重构或更换技术栈，不构成独立上架的充分理由。 + +开发者应优先考虑通过 Issue、Pull Request 或上游指定渠道贡献改进。适合合入上游的通用修复和增强，应先尝试向上游贡献，并在提交审核时提供记录及处理结果；无法贡献的，应说明具体原因。上游未回复、未合并或拒绝贡献，不自动构成独立上架的理由。修改仅涉及个人偏好或少量局部改进的，应自行维护，无需提交应用市场。 + +申请独立上架时，必须提供： + +- 上游应用名称、源码仓库、应用市场页面（如有）、派生所基于的版本或提交，以及保留的许可证和署名信息 +- 上游贡献记录，包括相关 Issue、Pull Request 或沟通记录的链接、日期和处理结果；没有贡献记录的，应如实说明原因 +- 与上游当前版本的具体差异、对应代码变更和可验证的使用场景，说明这些差异为何需要作为独立应用提供 +- 后续兼容性适配、安全修复、上游变更同步和用户支持的维护计划 + +以下情况**将被拒绝**： + +- 仅更换名称、图标、配色、字体、默认配置、布局细节或文案，未形成实质性的功能或使用场景差异 +- 仅包含少量缺陷修复、依赖升级、兼容性适配、代码重构或 AI 改写，既无足够的独立使用价值，也不符合 4.2.2 的接续维护要求 +- 仅以个人偏好、上游响应较慢、贡献未被接受或实现方式不同作为独立上架理由 +- 隐瞒派生关系、无法提供可核验的差异，或使用户误以为是上游官方版本、官方续作或获得上游认可 +- 无法说明独立上架的必要性，或无法提供与改动范围相匹配的持续维护计划 + +是否收录将综合考虑实质差异、用户需求、维护能力和市场内已有应用的重合程度，不以修改行数、提交数量或新增配置项数量作为通过标准。符合开源许可证的使用和分发条件，不代表必然符合应用市场的收录要求。 + +#### 4.2.2 停止维护应用的接续维护 + +以接续维护为由申请上架派生应用的，必须提供上游已明确停止维护的可核验证据，以及申请者已有的维护工作记录： + +- 上游维护者发布的停止维护公告、README 声明或明确回复，并附原始链接和日期 +- 上游仓库当前状态，包括是否归档、是否迁移，以及最近发布和提交情况；仅长期未提交、未发布或未回复，不能单独证明停止维护 +- 申请者向上游提交的 Issue、Pull Request 或接续维护沟通记录及结果；上游已归档、关闭贡献渠道或无法联系的，应提供相应证据，并说明没有贡献记录的原因 +- 派生后已完成的维护工作、对应代码和验证结果，以及后续维护计划；仅复制仓库或承诺未来维护，不足以申请上架 + +如果上游只是迁移仓库、更名，或已有明确的接续维护项目，应以实际维护中的项目作为比较对象，不得将旧仓库的归档状态作为停止维护的依据。 + +接续维护应用应清晰标注与原应用的关系，说明安装或迁移方式、配置与数据兼容性，以及能否与原应用共存。无法提供上述证据、存在误导性接续声明，或不能证明具备实际维护能力的应用**将被拒绝**。上游停止维护本身不保证通过审核，应用仍须满足本指南的其他要求。 + ### 4.3 插件 插件拥有后端代码、权限、接口、事件监听、数据库访问、文件访问或后台页面，会接受更严格的安全和权限审查。