如何重命名已发布公共Azure DevOps扩展中的Azure Pipeline任务
背景
我拥有多个Azure DevOps扩展，部分为近期开发，最早的可以追溯到2015年构建任务扩展模型首次发布时的任务。随着时间推移，Azure Pipeline领域发生了诸多变化，其中最大的变革出现在从UI驱动流水线转向YAML驱动流水线时，任务原本隐藏的内部属性也随之公开。
过去用户实际只会看到任务友好名称（Task's Friendly Name）和描述（Description），Team Foundation Server会通过TaskID（禁止变更的GUID）追踪任务真实身份。
示例如下：
"id": "3ca44a28-62de-4c60-8d77-a99065b95a8a", "name": "VariableSetTask", "friendlyName": "Set Variable", "description": "Sets a variable.", "author": "Jesse Houwing",
随着TFS 2017发布，任务可被打包到扩展中，由此产生了新标识元素：扩展发布者、扩展ID和贡献ID（Contribution ID）：
{ "id": "jessehouwing-vsts-variable-tasks", "name": "Variable Toolbox", "publisher": "jessehouwing", "contributions": [ { "id": "vsts-variable-set", "properties": { "name": "vsts-variable-set" } } ] }
这些元素在UI流水线时代同样处于隐藏状态，直到YAML普及后才公开可见。
steps: - task: jessehouwing.jessehouwing-vsts-variable-tasks-dev.vsts-variable-set.VariableSetTask@2
现在引用任务需要用到发布者、extensionid、contributionId和TaskName，无论是否通过「查看YAML」按钮插入任务。如果使用YAML助手，只有当组织中注册了两个TaskName属性相同的任务时，才会生成上述完整格式的引用。
命名调整需求
由于这些值现已公开可见，我希望改掉过去使用的不合理命名规则：
- 移除contribution-id中的
vsts-前缀 - 删除TaskName属性中的
Task后缀 - 所有字符改为小写，与微软官方任务命名规则对齐
- 最好还能更新仍带有
vsts-前缀的ExtensionId - 同时移除ExtensionId中的
jessehouwing字段
修改命名当然会对现有YAML用户造成影响，因为所有任务均通过名称而非ID引用，但这能让新用户以及从UI流水线迁移到YAML的用户更方便地使用我的任务。
现有平台限制
遗憾的是，应用市场设有防止扩展被劫持的保护机制，对Task ID（即GUID）有诸多强制约束：
- 同一扩展中发布的同一任务的所有版本必须使用相同GUID（为向后兼容，开发者可在单个扩展vsix中发布v1、v2、v3等多个版本，方便用户自主选择升级时机）。
- 同一个GUID只能在一个公共扩展中发布（私有扩展不受此限制）。
- GUID与ContributionId绑定，只要修改ContributionId就必须同时修改TaskID。
- 不能同时修改TaskID和TaskName。
这似乎意味着任务一旦随扩展发布，就无法修改其公开标识。如果尝试修改，市场会验证失败并返回错误信息：
ERROR: Contribution Microsoft.VisualStudio.Services.TaskId.VARIABLE-TRANSFORM is re-using task ID of some other contribution from earlier version. To publish the extension, change the task ID.
或者：
ERROR: All the task versions belonging to Contribution variable-transform should have the same task id. The tasks at variable-transform/v1 (version 1.4.41) and variable-transform/v2 (version 2.0.41) do not have the same ids.
已尝试的方案及其问题
我能想到的可行 workaround 是发布一个带有新ID、新Contribution Id、新Task Id和新TaskName的新扩展，但这需要该扩展的6000多名用户的组织管理员审批并安装新扩展，显然不现实。
我也可以接受ExtensionId无法修改的事实，直接在现有扩展中添加带有新名称、新ID的新任务，但这会破坏所有UI用户的自动更新功能。过去我投入大量精力实现扩展的无缝升级能力，比如变量任务从v1升级到v2时，通过添加别名和为输入字段设置合理默认值，将升级影响降到最低。输入类型从输入框改为下拉框，多个字段的YAML表示改为小写，同时根据下拉框选中值新增了多个选项，所有升级用户无需任何操作即可使用新功能。
如果TFS/Azure DevOps不将新任务识别为流水线中原有任务的新版本，那么UI流水线用户、旧Release流水线用户（以及几乎所有TFVC用户）都需要手动添加新任务副本，将原有配置全部复制到新任务后再删除旧任务，我不想给用户带来这么大的麻烦。
核心疑问
是否有遗漏的可选方案，既能让用户实现无缝升级，又能继续优化新用户通过YAML使用这些任务的体验？目前没有找到可以为任务本身（旧名称、GUID）或者Contribution id提供别名的方法，也没有找到在应用市场上重命名包含构建任务的扩展的途径。
内容的提问来源于stack exchange，提问作者jessehouwing
