Vyper 版本控制指南

动机

Vyper 有不同的群体被视为“用户”

• 智能合约开发人员（开发人员）

• 包集成商（集成商）

• 安全专业人员（审计员）

每组用户必须了解哪些编译器更改可能需要他们注意，以及这些更改如何影响他们使用编译器。本指南定义了每种编译器更改可能具有的范围及其对不同用户的影响，以便用户可以随时了解 Vyper 的进展。

群体	他们如何使用 Vyper
开发人员	使用 Vyper 编写智能合约
集成商	将 Vyper 包或 CLI 集成到工具中
审计员	了解 Vyper 的功能和安全问题

Vyper 的“公共 API”很大一部分是语言语法。语言语法是所有参与者与 Vyper 交互的主要接触点，因此从可靠性的角度讨论语言更改非常重要。用户期望所有用 Vyper 的早期版本编写的合约都能与更高版本无缝衔接，或者当这种情况不可能发生时，他们会得到合理的通知。Vyper 包本身及其 CLI 实用程序也具有定义明确的公共 API，它包含 Vyper 在 导出包 中提供的功能、包下顶级模块，以及所有 CLI 脚本。

版本类型

本指南改编自 语义版本控制。它定义了版本号的格式，类似于 MAJOR.MINOR.PATCH[-STAGE.DEVNUM]。我们将定期根据此格式发布更新，发布决策将遵循以下准则。

主要版本 X.0.0

对语法的更改不能以不向后兼容的方式进行，除非更改主要版本（例如 v1.x -> v2.x）。可以预期，在更新到新的主要版本时，许多功能会发生重大更改，主要是针对使用 Vyper 编译合约的开发人员。主要版本在发布之前会进行审计（例如 x.0.0 版本），所有 moderate 或 severe 漏洞将在审计报告中被解决。 minor 或 informational 漏洞也应该得到解决，尽管这可能会由 Vyper 的维护者决定。

群体	查找
开发人员	语法弃用、新功能
集成商	无更改
审计员	审计报告，包含已解决的更改

次要版本 x.Y.0

次要版本更新可能会添加新功能或修复 moderate 或 severe 漏洞，这些将在该版本的发布说明中详细说明。次要版本可能会以不向后兼容的方式更改包和 CLI 脚本提供的功能，这需要集成商注意。次要版本需要修复 moderate 或 severe 漏洞，但 minor 或 informational 漏洞可以在补丁版本中修复，并附带文档更新。

群体	查找
开发人员	新功能、安全漏洞修复
集成商	对外部 API 的更改
审计员	moderate 或 severe 修补程序

补丁版本 x.y.Z

补丁版本将用于修复文档问题、使用错误和在 Vyper 中发现的 minor 或 informational 漏洞。补丁版本应该只更新与外部 API 相关的错误消息和文档问题。

群体	查找
开发人员	文档更新、使用错误修复、错误消息
集成商	文档更新、使用错误修复、错误消息
审计员	minor 或 informational 修补程序

Vyper 安全

随着 Vyper 的发展，我们很可能会遇到某些语言功能的使用方式不一致以及编译器生成的代码中的软件错误。其中一些问题可能非常严重，会使用户的编译后的合约容易受到攻击，从而导致经济损失。当我们意识到这些漏洞时，我们将根据我们的 安全策略 来解决这些问题，并最终公布所有已报告漏洞的详细信息 在这里。这些问题的修复也将记录在 发布说明 中。

Vyper 下一步

可能有多个正在开发中的主要版本。对与现有语法不兼容的新功能的工作可以在一个名为 next 的单独分支上进行维护，它代表 Vyper 的下一个主要版本（以未经审计的状态提供，没有发布说明）。当前分支上的工作将保留在 master 分支上，并定期使用上述流程发布新版本。

除 master 中跟踪的内容之外，任何其他工作分支将使用 -alpha.[release #]（Alpha）来表示正在进行的更新，以及 -beta.[release #]（Beta）来描述最终打算发布的工作。 -rc.[release #]（发布候选版本）将仅用于表示主要版本之前的候选版本。将针对 -rc.1 版本请求审计，后续版本可能会合并审计期间的反馈。最后的发布候选版本将成为下一个主要版本，并将与总结结果的完整审计报告一起提供。

拉取请求

可以针对 master 或 next 分支打开拉取请求，具体取决于它们的内容。会增加次要版本或补丁版本的更改应该针对 master，而语法更改（如上所述）应该针对 next。 next 分支将定期针对 master 分支进行重新基准，以拉取添加到 Vyper 最新支持版本中的更改。

沟通

主要版本和次要版本应在适当的沟通渠道中告知最终用户，补丁更新通常不会进行讨论，除非有充分的理由。