删除GitHub旧Releases的最佳实践是什么？

• 第一步先做依赖排查
  公开仓库优先确认待删除的旧版本是否被下游项目、公共镜像源、公开教程/文档引用，直接删除会导致依赖方的构建、部署流程直接报错。如果是私有内部项目，只需确认内部团队的生产环境、CI流程没有锁定这些旧版本即可。
• 优先标记废弃而非直接删除
  除非旧版本存在涉密内容、严重安全漏洞、合规风险，否则不建议直接删除。更稳妥的方案是给过时版本的Release说明加上*已废弃（Deprecated）*标识，明确标注该版本存在的已知问题、停止维护的声明，同时附上推荐升级的版本号，既可以提醒用户不要继续使用旧版本，也不会误伤有历史版本回溯需求的开发者。
• 确需删除时的规范流程
  如果你确认必须删除超过1年的旧版本，请按以下步骤操作：
  1. 提前至少2周在项目README、最新Release公告、项目主页发布通知，明确告知旧版本的删除时间、影响范围、升级指引
  2. 本地完整备份所有待删除Release对应的源码包、二进制附件、对应提交的hash值，避免后续需要排查历史问题时无据可查
  3. 删除Release时无需删除对应的Git Tag，保留Tag可以给仍在引用旧版本的开发者留下自行拉取源码构建的路径，降低影响面
• 特殊版本保留建议
  如果你的项目遵循语义化版本规范，大版本的最终稳定版（比如v1.x的最后一个正式发布版）哪怕超过1年也建议至少保留归档，方便正在做版本升级的开发者做兼容性校验。

注意：GitHub的Release删除操作不可逆，删除后平台不会保留对应二进制附件、Release描述的备份，请确认所有前置操作完成后再执行删除。

内容的提问来源于stack exchange，提问作者Colin Curtain