cargosmart-release

大胆发布工作区中的 crate，并带有美观的半手工变更日志。

主要特性

• 零配置
  • cargo smart-release 无需额外标志即可智能地“做正确的事™️”。如果需要您的干预，它会在进行更改之前通知您。
  • 如果没有更改，它不会做任何事情。
• 专为多 crate 工作区设计
  • "无物孤立，万物相连" —— 这是它看待世界的方式，使其能够高效地处理复杂的工作区图。
  • 同样适用于单 crate 工作区
• 变更日志高级版
  • 它为您维护美观的变更日志，同时允许您进行最终润色。
  • 通过存储库中的 标签对象 和 GitHub 发布 查看您的发布说明
  • 与 cargo release 紧密配合
    • cargo changelog 非破坏性写入变更日志，只写变更日志，将发布工作流程留给 cargo-release。

如果您相信所见即所得，这里有 12 分钟演示，以及 30 分钟的版本 也可用。

为该工作流程而设计

在开发工作区中的各种 crate 时，在提交更改并如果编辑是破坏性更改、功能或我在变更日志中想要看到的其他更改时，将使用 conventional git 消息。这有助于稍后自动构建变更日志框架。

当准备发布特定的crate或一组感兴趣的crate时，运行cargo smart-release [<crate-name> ...]来模拟发布。对于特别详尽但易出错的模拟（如假阳性），可以运行cargo smart-release --dry-run-cargo-publish。为了完善变更日志，运行cargo changelog --write <crate-name>来更新框架并手动编辑，直到符合要求。

在评估发布流程并遵循说明后，运行cargo smart-release --execute将导致一个或多个crate的完全自动发布。

还有一些其他选项在常见情况下可能不需要，使用cargo smart-release --help查看它们。

安装

Cargo

通过cargo，可以使用rustup获取

cargo install cargo-smart-release

特性

• 安全使用，实际上执行操作需要--execute标志
• 通过尽可能使操作原子化来避免不一致的状态，充分利用gitoxide技术
• 优雅地处理工作空间依赖和循环，允许一次调用发布多个crate
• 如果没有更改，避免进行任何发布
• 如果当前版本未发布，避免增加版本，允许您通过编辑cargo清单来控制版本
• 常规提交消息驱动变更日志框架，并自动推导出要发布的crate版本
• 如果自上次发布以来已更改，自动发布依赖的工作空间IDP crate以及所需的crate
• 自动调整清单版本并更新使用版本增加的crate的清单
• 在考虑破坏性更改的情况下保守地增加下游工作空间crate，即使这些crate不会发布，也使得下游破坏成为不可能
• 使用git标签来了解crate是否发生变化，如果完全没有代码更改，则跳过发布
• 过于急切地发布，应该有一种方式来控制补丁发布。
• 处理预发布版本，如1.0.0-beta.1
• 支持除'origin'之外的其他远程名称 - 目前假定后者名称。通过获取当前签出的分支的远程来修复
• 正确处理版本规范 (表格与值)
• 正确处理所有版本比较器（见这里了解如何实现）
• 自动检测crate更改是否破坏性，以建议正确的版本增加

与cargo release的比较

cargo-release是此工具存在的原因，因为它让我沉迷于一个了解git的全自动发布工作流程。截至2021-08-12，它非常适合简单的或单个crate的工作空间，所以请使用它：cargo install cargo-release。

cargo smart-release的工作方式有所不同：“它尽力在发布gitoxide crates时做我最想做的事情。”

• 为了安全执行，默认情况下它是禁用的
• 指定一个或多个crate，并自动检测哪些crate需要发布
• 以增加整体成功的机会的方式处理依赖循环
• 当出现问题时要尽力确保工作空间处于一致状态
• 是gitoxide的游乐场，让它有理由使应用作者（即自用）的工作更加方便和可行
• 创建更改日志时不会破坏性地进行，同时还有注释标签和GitHub发布

局限性

• 在指定版本时需要使用表格，即crate = { version = "1" }而不是`crate = "1"`。
• 当遇到不是^的版本要求比较器时，它会优雅地失败
• 它只在gitoxide上使用过，只有很少的回归测试，覆盖面很小。
• 更改日志中的简短对象ID可能具有歧义，因为它们无条件地截断为7个字符。
• 如果列表项是由提交消息填充的，并且这些项本身也包含列表项，则回溯将失败。理想情况下，只有同一级别的项目可以被解析。
• 它非常年轻，可能试图吃内衣
• 它需要一个git仓库来管理工作空间