GitHub Releases版本管理与CDN链接使用相关问题咨询

1. 极小修改是否需要每次新建Release？ #

• 不需要。GitHub Release 是用于对外发布正式可使用的版本的功能，仅内部测试、未到对外发布节点的临时修改不需要打标签发Release。只有当你需要固化当前代码状态供外部用户使用、或者正式对外发布修复/功能更新时，再创建对应Release即可。

2. v1.1、v2.0 版本升级时机 #

遵循通用的语义化版本（MAJOR.MINOR.PATCH）规则即可：

• PATCH位升级（如v1.0.0→v1.0.1）：仅做了向下兼容的问题修复时升位
• MINOR位升级（如v1.0.x→v1.1.0）：新增了向下兼容的功能时升位
• MAJOR位升级（如v1.x.x→v2.0.0）：存在不向下兼容的破坏性改动时升位

对应分支、标签的管理规则：通常每个MAJOR版本对应独立的长期维护分支，比如v1.x分支对应所有1开头的版本迭代，v2.x分支对应所有2开头的版本迭代，每个正式发布的版本都需要打一个和版本号完全同名的标签。 #

3. 新增文件夹后@1.0 CDN链接无法访问的问题排查 #

你遇到的问题通常是两种原因导致：

• 标签打在了错误的提交上：确认你打v1.0.1标签时，是在已经新增folder_02的最新提交上打的操作，且标签已经成功推送到GitHub远端。如果标签打在未新增文件夹的旧提交上，Release对应的代码状态就不包含folder_02，CDN自然无法拉取到对应内容。
• CDN缓存未更新：多数CDN的@x.y规则会匹配最新的x.y.*版本，如果你发布v1.0.1后CDN的旧缓存还未过期，就会继续返回之前v1.0.0的内容，看不到新增的文件夹。

4. GitHub Releases 搭配 CDN 使用的规范 #

• 打标签前必须确认当前提交是需要发布的正确代码状态，标签名与Release版本号完全一致，标签推送到GitHub远端后再生成正式Release，避免版本对应错误。
• 版本号严格遵循语义化规则，不要出现版本号混用、跳跃的情况，保证CDN的版本解析逻辑正常生效。
• 每次发布新版本后如果需要立即生效，主动清理对应版本范围的CDN缓存，避免旧缓存影响访问。

内容的提问来源于stack exchange，提问作者Maayan P