银河系维护者指南

Preface

本文档记录了维护 Winter CMS 存储库所涉及的过程。这是为了让项目的维护者清楚地了解如何审查和管理代码的流入，并确保维护 Winter CMS 及其第一方插件的质量和理念。

Winter CMS 项目是 2021 年 3 月 5 日发生的一次分叉的结果，此前 October CMS 的维护者小组明显地意识到 October CMS 的原始创始人无意与维护者小组合作。分叉公告 详细介绍了发生的情况以及分叉的原因。

本文档最初是为 October CMS 编写的，但已改用于 Winter CMS。

Roles

该项目被认为是一个平面管理级别，所有维护人员对项目负有同等责任。目前的维护者（截至2021年10月11日）如下：

Luke Towers 被维护者小组指定为首席维护者，是 October CMS 服务时间最长的维护者。

主要理念

Winter CMS 的运作理念是“一切都应该尽可能简单，但不要更简单”，就像之前的 October CMS 一样。这句话被归因于阿尔伯特·爱因斯坦（尽管这一直存在争议)，并简洁地描述了 Winter CMS 的精神。

作为代码库的仲裁者，维护者应该努力确保随着系统功能和潜力的增加，仍然要仔细考虑以确保所提议的代码对开发人员来说易于开发并且对用户来说易于使用。

由于 Winter CMS 旨在成为滚动更新的“常青”产品，因此必须特别注意保持向后兼容性，并允许 Winter CMS 和第一方插件的所有用户通过更新继续使用产品而不会出现问题。

同时，Winter CMS 对其用户有责任确保遵循安全和代码方面的最佳实践。

在可能的情况下，Winter CMS 遵循 Laravel 框架的 LTS（长期支持）版本作为基础框架，其中确实包括根据需要弃用不受支持的 PHP 版本。

Projects

Winter内容管理系统

以下协议适用于所有当前和未来的存储库@wintercms 组织。这包括Winter内容管理系统 和风暴图书馆 存储库，以及它的installer 和documentation.

主要分行

Winter CMS 和 Storm 库都有一个主要的存储库分支 -develop，其中存储了当前分支上下一个版本的所有正在进行的开发。这两个存储库还包含每个主要发布分支的分支（包括旧的， 生命周期结束的分支机构可能仍会不时收到小的更新和安全修复程序）。

对于安装程序和文档存储库，main 分支代表最新的开发快照。致力于main 分支可以根据需要进行，只要提交很小并且在提交消息中有明确的解释和证明。拉取请求用于较大的提交仍然是首选。没有develop 这些存储库的分支。

Milestones

Winter CMS 存储库使用里程碑来跟踪每个构建将发布哪些更改。

在这些例子中v1 反映了 Winter 努力从不引入大量破坏性更改的事实，第二个数字与该分支支持的 Laravel LTS 版本相关联，最后一个数字代表该分支的发布号。当前的 Winter CMS 分支及其相关的 LTS 发布版本如下：

一个里程碑代表upcoming 要发布的构建将出现在所有传入的代码更改中，以及代表next 为风险稍高的问题/PR 发布构建，并延迟到下一个版本以避免阻止当前版本。此外，下一个分支的第一个版本的构建里程碑将出现，以表明问题/PR 具有潜在的破坏性更改，这些更改将被延迟到下一个引入下一个 Laravel LTS 版本的主要分支。例如，如果最后发布的版本是v1.1.7, 会有一个里程碑v1.1.8 和v1.2.0.

在适当的时候，维护者将认为一个里程碑被锁定，除了错误修复或维护之外的进一步更改，以便继续发布构建。在这些情况下，不应将新问题或 PR 分配给里程碑，除非它们是错误修复或某种形式的维护。不应为这些里程碑分配新功能。

一旦维护者发布构建，Milestone 应该完全锁定并关闭。

审查问题和拉取请求

维护人员必须审查向 Winter CMS 存储库提出的所有问题和拉取请求，以确保它们符合代码质量标准并遵守 Winter CMS 的原则。

维护者应该关注的问题应该包括：

在审查拉取请求时，维护者应努力查看以下内容：

贡献者提交的拉取请求必须提交给develop 分支或功能或修复分支。

拉取请求还应指出他们解决的任何问题——这应规定为“修复 #...”，后跟拉取请求线程的初始（开始）评论中的问题编号。

维护者可以自由要求对问题和 PR 进行澄清，并向提交者寻求更多信息。如果没有更多细节，维护者可能会关闭问题或 PR。此外，问题和 PR 在 60 天不活动后会自动关闭（这只是为了将重点放在对用户重要的事情上，自动关闭的问题会在请求时愉快地重新访问）。

为了跟踪问题和拉取请求的进度，我们使用 GitHub 的标签和里程碑系统来记录当前状态。我们的标准标签 指定拉取请求或问题的类型（即增强、维护、讨论或错误报告）、状态（即进行中、已完成或需要响应或修订），有时还指定优先级（即关键、高或低）。一般来说，一个问题应该有一个类型标签和一个状态标签。

一旦决定构建，里程碑应设置为将在其中发布的构建的里程碑。

合并拉取请求

当一个 Pull Request 被分配给current 构建里程碑，它可以合并到develop 分支。维护者应该使用挤压和合并 GitHub 中的一个选项，用于将 PR 压缩为一个提交，然后合并到develop 分支。此函数使用 PR 的名称创建一个提交，后跟括号中的 PR 编号，以提供返回合​​并的 PR 的快速且有用的链接。请注意，如果 PR 的提交历史为项目提供了有意义的价值，而不会将其与不必要的提交混为一谈，则可以使用 Merge Commit 将 PR 的历史也包含到项目中，而不是将其压缩为一次提交。

如果适用，提交消息应包含有关合并 PR 的额外信息——这应包括更改的任何理由和将来可能需要的重要信息参考。

以 PR 和提交的形式提供修复或帮助的用户在 Git 中得到了适当的归属，但是，如果有人在 Git 之外提供帮助（即通过 Discord 或社区中的其他地方），通常礼貌地将他们归功于犯罪。

信贷应以以下形式提供Credit to @username 在提交描述中。

此外，还应链接任何已修复或引用的问题或 PR，标记为Fixed: 或者Refs: 分别。 GitHub 将自动链接添加到同一存储库的任何问题编号，但外部存储库应链接为 URL。

示例提交消息如下：

Fix some issues in the code (#1234)

This fixes a couple of issues spotted in the Backend. The changes are minor and should not affect backwards compatibility.

Credit to @bennothommo. Fixes #1212 and https://github.com/wintercms/wn-blog-plugin#432

合并的拉取请求 - 以及拉取请求解决的任何关联问题 - 应该具有Status: Completed 分配给它们的标签和所有其他状态标签都应该取消分配。如果拉取请求还没有分配构建里程碑，这也应该更改为当前构建里程碑。

维护者的标准工作流程

在可能的情况下，在 Winter CMS 上完成的所有工作都应通过拉取请求完成。拉取请求让所有维护者有机会审查提议的更改并提供反馈或确定任何感知到的问题，此外还允许自动化测试在代码质量或我们的测试场景到达主要分支之前发现任何问题.

维护者应该为他们传入的更改创建一个分支——使用以下格式作为分支名称：

必须向develop 分支并提供简洁的描述作为拉取请求的标题，并提供其他维护人员了解实施的更改所需的更多信息。

直接承诺develop 应尽可能避免分支以支持拉取请求。存在一些直接提交的情况develop 可能需要：

发布流程

发布过程是由维护者负责发布新版本的 Winter CMS。

维护者为发布采取以下步骤：

第一方插件

以下协议适用于 Winter CMS 组织中发布的所有第一方插件。请注意，许多过程与 Winter CMS 相同，因此本节定义任何differences 在要使用的过程中。

主要分行

所有第一方插件存储库都包含main 分支是插件的所有贡献的共同努力。维护者可以提交更改main 根据需要分支，但与 Winter CMS 存储库一样，仍然首选在拉取请求中完成实质性更改或新功能或更改功能。

Milestones

第一方插件，如 Winter CMS 存储库，使用里程碑来跟踪哪个版本的插件实现了哪些更改。第一方插件中的里程碑使用更“语义化”的版本控制，因此具有主要、次要和点版本的格式major.minor.point.例如：

以下情况将确定需要更改哪个版本号：

维护者应该确保minor 和一个point 里程碑始终可用于第一方插件，并使用他们的最佳决定来确定哪个是所有传入 PR 和问题的适当里程碑。

审查问题和拉取请求

维护者应该使用Winter CMS 的相同流程 在审查第一方插件的问题和 PR 时。

应向main 始终分支，除非它是要合并到父功能分支中的子功能分支。

对于包含更改的拉取请求updates/version.yaml 文件，维护者应该要求贡献者不要在他们的拉取请求中包含这些更改。该文件只应作为发布流程.

合并拉取请求

与审查问题和 PR 一样，第一方插件使用与 Winter CMS 相同的流程 合并拉取请求时。

维护者的标准工作流程

第一方插件的工作流程是和冬天一样，除了维护者可以提交更改main 分支而不是develop 根据需要分支。与 Winter CMS 一样，仍然建议实施更改的主要机制是拉取请求。

发布流程

在发布新版本之前，维护者应确保分配给新版本里程碑的所有任务都已完成并合并到main.一旦完成，维护者应该更新updates/version.yaml 包含新版本的文件，以及更改的单行摘要。这些单行更改的一些示例可以在下面找到：

如果此版本中还包含迁移，则应将其附加为更新下方的数组项。看文档 有关应如何格式化版本更新条目的示例。

完成此提交后，应关闭此版本的里程碑，并应在 GitHub 中为插件创建一个新版本。发布版本提供更详细的版本说明，并链接回里程碑和相关 PR，为插件用户提供更多关于版本之间插件更改的上下文。该版本还使用版本标记存储库。版本名称应采用以下格式v<major>.<minor>.<point> 发行说明的详细信息应按顺序包含以下内容（如果适用）：

对于每个部分中的每个项目，最好包含一个指向实现更改的 PR 的链接，或者如果直接完成，则包含提交main.

在发行说明的底部，应提供一个指向里程碑的链接，以便人们快速查看all 该版本中实施的更改。

有关发布的示例，请参阅以下内容：

豫ICP备18041297号-2
Please enter a query in order to search.