rust - 在发布时使用最新版本的依赖关系是一种好习惯吗？

Question

我正在建立一个使用一些依赖项的 crate ，并且要发布它，我必须指定依赖项的版本。我将dep = "*"替换为dep = ">=N"，将N替换为每个dep可获得的最新版本，即cargo update之后的最新版本。

我应该放松/降低所需的版本吗？

我该怎么办？我尝试将dep = "M"设置为更低的版本号M，但cargo仍在使用较新的版本。是否有工具来查找构建和测试我的 crate 所需的最低M？

Answer 1

在The version field下，《 cargo 手册》规定:

Cargo bakes in the concept of Semantic Versioning, so make sure you follow some basic rules:

• Before you reach 1.0.0, anything goes, but if you make breaking changes, increment the minor version. In Rust, breaking changes include adding fields to structs or variants to enums.
• After 1.0.0, only make breaking changes when you increment the major version. Don’t break the build.
• After 1.0.0, don’t add any new public API (no new pub anything) in patch-level versions. Always increment the minor version if you add any new pub structs, traits, fields, types, functions, methods or anything else.
• Use version numbers with three numeric parts such as 1.0.0 rather than 1.0.

如果依赖项的维护者已采用并正确应用了这些规则，则在给定该依赖项的特定版本(您知道自己要使用的包装箱)之后，相同主版本的任何后续修补程序发行版都应该一直有效，而后续的次要发行版也应始终有效。只要主版本号不为0，相同主版本号的应当也始终可以工作。
作为Herman L alludes，您可以使用插入符号前缀指定您想要最新的此类“兼容”发行版。他将您带到 cargo 书中有关Specifying Dependencies的章节，其中解释了:

Caret requirements

Caret requirements allow SemVer compatible updates to a specified version. An update is allowed if the new version number does not modify the left-most non-zero digit in the major, minor, patch grouping. In this case, if we ran cargo update -p time, cargo should update us to version 0.1.13 if it is the latest 0.1.z release, but would not update us to 0.2.0. If instead we had specified the version string as ^1.0, cargo should update to 1.1 if it is the latest 1.y release, but not 2.0. The version 0.0.x is not considered compatible with any other version.

Here are some more examples of caret requirements and the versions that would be allowed with them:

^1.2.3  :=  >=1.2.3, <2.0.0
^1.2    :=  >=1.2.0, <2.0.0
^1      :=  >=1.0.0, <2.0.0
^0.2.3  :=  >=0.2.3, <0.3.0
^0.2    :=  >=0.2.0, <0.3.0
^0.0.3  :=  >=0.0.3, <0.0.4
^0.0    :=  >=0.0.0, <0.1.0
^0      :=  >=0.0.0, <1.0.0

This compatibility convention is different from SemVer in the way it treats versions before 1.0.0. While SemVer says there is no compatibility before 1.0.0, Cargo considers 0.x.y to be compatible with 0.x.z, where y ≥ z and x > 0.

但是，当然，某些软件包维护者可能会忽略SemVer，而采用其他版本控制方案；可能尝试使用SemVer，但应用不正确；或可能在无意识的情况下无意中做出了重大更改。幸运的是，最受欢迎的 crate 相当活跃且维护良好，而根据我的经验，此类问题相对罕见。 Rust的强类型系统还通过防止许多此类重大更改甚至被编译而提供了一些额外的保护，因此它们通常很早就被捕获。
当然，所有重大更改都应由集成测试(构建管道始终确保发布之前通过该测试，对吗？)承担。 Dependabot之类的组件还可以提醒您发布后更新的依赖项(例如，通过创建PR)，这又可以触发CI管道针对新的依赖项版本立即运行测试套件并报告结果。
可能有充分的理由采用不同的方法，但是在大多数情况下，上述做法在很大程度上是明智的。