publish-cool-package

这是一个分支！

这是 gitoxide/cargo-smart-release 的分支。你可能不想使用这个包。这是为了支持特定的发布流程。 https://github.com/Byron/gitoxide

无畏地发布工作区 crates，并生成美观的半手工更改日志。

主要特性

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

如果眼见为实，这里有 12分钟演示，30分钟的也有 可用。

为这个工作流程而设计

当在工作区中开发各种crates时，提交更改，如果编辑是破坏性更改、特性或其他我希望在更改日志中看到的变化，将使用 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 cool-workspace

特性

• 作为实际执行操作需要使用--execute标志，所以是安全的
• 通过尽可能使操作原子化，利用gitoxide技术的最大优势来避免不一致的状态
• 优雅地处理工作区依赖和循环，允许一次发布多个crate
• 如果没有更改，则避免进行任何发布
• 如果当前版本尚未发布，则避免增加版本，允许您通过编辑cargo清单来控制版本
• 约定式提交信息驱动变更日志脚手架，并自动推导出要发布的crate版本
• 如果自上次发布以来它们已更改，则自动发布依赖的工作区IDP 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 crate 工作空间时，非常努力地做我最希望做的。”

• 确保安全执行，因此默认情况下它是禁用的
• 指定一个或多个 crate，并自动检测哪些 crate 需要发布
• 以增加整体成功的机会的方式来处理依赖循环
• 非常努力地确保当出错时工作空间保持一致状态
• 为 gitoxide 提供一个理由，使其对应用程序作者（即 dog-fooding）来说更加方便和可行
• 以非破坏性方式创建更改日志，包括注释标签和 GitHub 发布

限制

• 指定版本时需要使用表格，即 crate = { version = "1" } 而不是 `crate = "1"`。
• 当遇到不是 ^ 的版本要求比较器时，它会优雅地失败
• 它仅在 gitoxide 上进行了测试，只有非常少的回归测试，覆盖率很小。
• 更改日志中的短对象 ID 可能是模糊的，因为它们无条件地截断为 7 个字符。
• 当用户内容被更改日志重写时，如果它们不是 'inline' 形式，则会丢弃链接
• 它非常年轻，可能试图吃内裤
• 它需要一个 Git 仓库来管理工作空间