Spring Cloud 持续受到欢迎，在过去几年中，许多 IaaS 提供商都提供了与其技术的集成并加入了发布列车。这通常涉及加入 spring-cloud GitHub 组织并在 org.springframework.cloud Maven groupid 中发布。随着包含的项目数量的增加，它变得有点笨重，我们希望退一步，回顾一下此模型提供的优缺点，并提出更好的前进方向，使所有参与的项目受益。

也许成为发布列车一部分最大的缺点是它消除了项目维护者一定程度的控制。由于 Spring Cloud 核心团队负责发布，维护者无法根据他们集成的技术的进度安排工作。或者，即使他们设法发布了服务更新，在下一个发布列车版本发布之前，发布列车也不会接收它。此模型还意味着项目维护者通常无法直接访问关键统计信息，例如其项目的 Maven 下载次数。

此外，成为发布列车一部分似乎有很多好处，但实际上，其中许多好处是任何项目都可以获得的好处，而不是与加入发布列车或 spring-cloud GitHub 组织有任何关系。

• Spring Cloud 团队定期与外部项目合作，以帮助审查它们并提供关于如何最好地与 Spring Cloud 集成的建设性反馈。(如果您需要反馈，请联系我们。)
• 人们认为它更容易在 start.spring.io 上获得那个难以捉摸的复选框。这是不正确的。关于如何确保项目的开发适合 start.spring.io，有一些 指南，但是关于包含的决定不仅仅是遵循命名方案。我们是否发现社区正在采用该项目集成的技术？该项目是否建立了一个充满活力且可持续的社区，确保其长寿命和健康的代码库？是否有足够的文档、指南等来展示如何使用该项目？指南中没有任何内容需要包含在 Spring GitHub 组织中。
• Spring 团队定期制作涉及第三方项目的内容，重点介绍关键版本或增强功能。无需成为发布列车的一部分即可实现此目的。

https://springframework.org.cn 网站显然包含涵盖主要 Spring Cloud 项目的内容，但它还包含涵盖一些第三方项目的内容。这可能是展示如何使用该技术的指南，或者是在现有项目页面上的一个条目。请参阅 https://springframework.org.cn/projects/spring-cloud，其中引用了许多项目——其中一些在列车上，一些不在列车上。

由于这些原因，Spring Cloud 团队已决定转向一个简化发布列车的模型，使我们能够解决缺点，同时保留所有感知到的好处。该提案是 IaaS 提供商将在他们自己的 GitHub 组织中托管和维护其代码。这适用于当前发布列车上所有现有的集成。Spring Cloud Azure 从未加入列车，Spring Cloud Alibaba 团队在从孵化器组织毕业时已经采用了这个新模型。

这在实践中意味着什么？

从 Spring Cloud GitHub 组织和发布列车中删除某些项目并非说明积极开发或支持策略的变化。相同的团队将继续致力于这些项目，跟上 Spring Cloud 版本的发布。如果有什么不同的话，这种变化可能会使支持模型更加清晰：如果项目托管在 IaaS 提供商的 GitHub 组织中，那么他们显然正在提供支持。

新的模型确实意味着 group-id 可能会发生变化，artifact-id 也可能会发生变化。包名称也可能会更新以反映这些更改。开发人员还需要在他们的项目中显式包含这些依赖项，而不是通过 Spring Cloud BOM 中的管理版本继承它们。

Spring Boot 团队有 指南 用于模块（自动配置和启动器）的适当命名。这些对于 Spring Cloud 并非严格强制执行，但遵守这些指南意味着任何基于该方案构建的内容都将“正常工作”（例如，IDE 中的内容辅助工具）。

遵循此模型，Alibaba 团队正在从 spring-cloud-incubator 毕业到他们自己的 GitHub 组织 https://github.com/alibaba/spring-cloud-alibaba，我们将继续与他们合作，因为他们本周将发布一个重要的版本，该版本支持 Spring Cloud Greenwich.SR2 和 Finchley.SR4。此版本将包括对 Spring Cloud Gateway 的 Sentinel 支持，并支持 Nacos 服务发现和 Spring-Cloud-Config 协同使用。敬请期待！

您可以预期其他提供商将在未来主要 Spring Cloud 列车发布期间迁移，因为重大版本发布是进行此类重大更改的正确时机。

请注意，这纯粹是在描述目前主要 Spring Cloud 列车的情况和计划；它不会影响其他项目（例如，Spring Cloud Stream 绑定器）。

我们希望上述理由解释了我们试图通过此策略实现的目标。与往常一样，我们乐于接受反馈——请让我们知道您的想法。让项目所有者拥有充分的灵活性来构建和发布与其文化更好地匹配的软件，同时继续提供与我们密切合作进行代码审查和项目推广的所有好处，应该对每个人都有利。