MySQL 版本号命名规则悄然调整
近期开发者通过 Homebrew 升级数据库时发现,MySQL 的版本号规则出现明显变动,直接从 9.x 跨越至 26.7.0。这一跳跃式升级引发了社区关注。使用包管理工具维护本地开发环境的开发者,需要留意这一命名策略的变化,以便在后续的版本升级和依赖管理中及时调整认知,适应官方的发布节奏。
近期开发者通过 Homebrew 升级数据库时发现,MySQL 的版本号规则出现明显变动,直接从 9.x 跨越至 26.7.0。这一跳跃式升级引发了社区关注。使用包管理工具维护本地开发环境的开发者,需要留意这一命名策略的变化,以便在后续的版本升级和依赖管理中及时调整认知,适应官方的发布节奏。
针对国内开发者在使用 Homebrew 进行 `brew update` 和 `brew upgrade` 时频频遇到报错或卡顿的问题,社区提出了一种“混搭”镜像源的临时解决方案。 **核心问题分析**: Homebrew 升级到版本 6 之后,采用了拆分式的 `api.json` 结构并引入了加密验证。这导致国内许多主流镜像源在同步时出现滞后或不完整的情况:部分镜像源同步了 API 但 Git 仓库失效,而另一部分则是 Git 正常但 JSON 数据未同步。 **解决方案**: 通过将不同高校的镜像源进行混搭来规避上述问题。具体配置为: 1. 将 Git 远程仓库(`HOMEBREW_BREW_GIT_REMOTE` 和 `HOMEBREW_CORE_GIT_REMOTE`)指向**上海交通大学(SJTU)**镜像源; 2. 将 API 和 Bottle 域名(`HOMEBREW_API_DOMAIN` 和 `HOMEBREW_BOTTLE_DOMAIN`)指向**浙江大学(ZJU)**镜像源。 这种“交大 Git + 浙大 API”的组合能够有效绕过单一镜像源同步不全的缺陷,恢复 Homebrew 的正常更新与下载。