动作作者：迁移到 V2 与维护 V1 兼容版本

如果你已经分享过动作，迁移到 V2 时可以继续维护同一个分享网址，并为两代 Quicker 提供不同的可安装内容。本文介绍如何选择维护范围；具体分享入口和版本要求见分享动作与公共子程序。

先决定支持哪些用户​

保留一个可安装的 V1 版本，不等于承诺持续维护它。是否为 V1 修复问题、支持哪些环境，由作者根据实际情况说明；不需要为了两版功能一致而放弃 V2 的新能力。

迁移前保留可工作的版本​

在修改动作之前，保留已验证的 V1 动作、公共子程序及必要的外部文件，并记录 Quicker 版本和分享修订号。服务器的历史修订用于分发与追溯，不能替代自己的开发备份。

本地可以用副本测试，但副本不会沿用原动作的分享关系。正式更新时，应从原分享关联的动作进入分享窗口，确认是在更新原分享，避免把测试副本误发成新的动作网址。

客户端安装、账号数据迁移和回退步骤见从 V1 迁移到 V2。账号数据迁移与动作库分享更新是两件事，不能把 V2 本地数据直接当作 V1 备份恢复。

从同时支持两版转向仅发布 V2​

1. 确认原分享已有一个可正常使用、可分发的 V1 修订，并记下修订号。
2. 在 V2 中修改和测试动作，核对公共子程序和外部依赖。
3. 打开完整分享窗口，确认原分享身份，填写本次更新说明。
4. 在本次发布格式中取消 V1，保留 V2。
5. 发布后检查版本历史，确认新修订标记为 V2；需要审核的内容按网页状态等待处理。
6. 在动作介绍中写明 V1 保留在哪个修订，哪些新增功能需要 V2。

例如，r10 同时包含 V1/V2，之后发布的 r11 仅包含 V2。r11 可分发后，V2 用户可以获得 r11，V1 用户仍使用 r10 中的兼容内容。取消本次 V1 发布不会删除 r10，也不会把 r11 的 V2 内容推给 V1。

只有 V2 内容、从未提供过 V1 的新分享，则没有可以留给 V1 用户的兼容修订。

兼容检查通过后仍要测试​

分享检查会识别部分不支持的模块、参数选项和结构，但不能证明所有运行行为兼容。计划同时支持两版时，应分别验证：

• 常用流程，以及取消、空输入和失败时的处理；
• 条件分支、子程序和网络共享依赖；
• 表达式、C# 脚本、第三方程序集与软件环境；
• 用户原有设置或数据在更新后是否仍能使用。

对于版本间的少量运行差异，可以使用获取系统或动作信息提供的 Quicker 版本号作判断。但 V1 不认识的模块或结构，即使放在不会执行的分支里，仍可能无法生成 V1 兼容内容。

若提示“无法生成 V1”，可以仅发布 V2。若提示“兼容性需验证”，先按提示验证目标版本；不能仅凭动作在 V2 中运行成功就承诺支持 V1。

后来还要补修 V1 时​

使用保留的 V1 开发备份进行修复和验证，并在正式发布前确认更新的是原分享、本次只提供 V1 内容。不要用旧版正文覆盖正在维护的 V2 内容。

同一个分享的修订号共同递增，但两种格式分别保留当前分发版本。当前 V2 更新机制优先选择 V2，只有没有 V2 时才使用 V1。

例如，r11 仅更新 V2，之后 r12 仅补修 V1：在两者均可分发的情况下，V1 用户获得 r12，V2 用户继续获得 r11。发布前后请核对版本历史中的格式标记，并注意两版仍共用动作介绍和分享管理状态。

把支持范围写在动作介绍中​

同一个分享共用介绍，V1/V2 功能不同时应标明适用范围。下面是可按实际情况修改的示例，修订号和版本号均需替换：

版本支持说明
- V1：最后兼容版本为 r10，已在 Quicker 1.x 的实际测试版本中验证。
- V2：从 r11 起使用 V2 专属功能，最低版本见分享要求。
- 新增的批量处理功能仅在 V2 版本提供。
- V1 后续维护范围：只修复影响基本使用的问题，不再增加新功能。

如果不再维护 V1，直接说明“V1 保留 r10，后续不再更新”即可。保留修订不能保证外部网站、软件或服务变化后仍永久可用。

收集反馈时，请用户同时提供 Quicker 版本、动作修订号、具体操作和错误信息，避免把版本功能差异误判为故障。