Apache Thrift Rust crate 发布指南从 crates.io 账户配置到cargo publish全流程【免费下载链接】thriftApache Thrift项目地址: https://gitcode.com/gh_mirrors/thrift2/thriftApache Thrift 的 Rust 运行时库thriftcrate位于 lib/rs 目录是构建 Thrift 客户端与服务端的基础依赖其发布流程由 RELEASING.md 正式定义。本指南完整讲解该 crate 的发布操作一次性配置 crates.io 账户、语义化版本号要求、自动化脚本发布与手动发布两种路径并结合仓库中的 release.sh、Cargo.toml 与构建脚本源码说明每一步背后的原理与常见坑点。读完后你将能独立完成一次 Apache Thrift Rust crate 的版本发布。发布总览两大步骤发布thriftcrate 的整体流程并不复杂分为两个主要阶段设置 crates.io 账户一次性——准备用于发布包的身份凭证与 API Token打包并发布 crate 本体——更新版本号、校验打包内容、执行cargo publish。其中第二阶段既可以通过仓库自带的自动化脚本 release.sh 一键完成也可以按手册逐步操作。下文先讲一次性账户准备再分别展开自动化与手动两种发布路径。第一步一次性设置 crates.io 账户发布 crate 前需要先在 crates.io 上完成身份配置该步骤只需执行一次打开 crates.io 站点点击右上角Log In按钮登录。务必使用对 thrift 仓库拥有写权限的 GitHub 账号登录——crates.io 通过 GitHub OAuth 关联身份发布权限与仓库权限直接挂钩。点击右上角的用户头像按钮选择Account Settings账户设置。在API AccessAPI 访问区域点击New Token生成一个新的 API Key。这是cargo向 crates.io 发布包时使用的凭证。生成的 API Key 需要妥善保存。如果你只打算用这个 GitHub 账号向 crates.io 发布 crate可以按照 crates.io 页面提示将生成的 Key 保存到~/.cargo/credentials文件中。该文件是 cargo 的全局凭证存储位置保存后cargo publish将自动读取无需每次手动cargo login。第二步发布前必须明确的版本号规则在执行任何发布操作前请先确认版本号格式。cargo要求 crate 版本号遵循**语义化版本Semantic Versioning**规范THRIFT_RELEASE_VERSION必须包含 major、minor 与 patch 三个数字段即必须形如#.##.##例如0.21.0。这一点在仓库中是有硬性校验的。release.sh 的脚本开头就使用正则^0-9{2}$校验入参不符合该格式会直接打印用法说明并退出if ! [ $# -eq 1 $1 ~ ^[0-9{2}$ ]]; then (2 echo Usage: ./publish-crate.sh [THRIFT_RELEASE_VERSION] ) (2 echo THRIFT_RELEASE_VERSION is in semantic versioning format, i.e. #.##.##) exit 1 fi以当前仓库 lib/rs/Cargo.toml 为例crate 版本为0.21.0这是符合语义化版本三段的典型示例。路径 A自动化发布仓库在 lib/rs 目录下提供了发布脚本 release.sh只需一条命令即可完成从改版本号到发布的全过程./release.sh [THRIFT_RELEASE_VERSION]前提条件使用自动化脚本要求你已将 crates.io 的 API Token 存入~/.cargo/credentials因为脚本内部不会再执行交互式的cargo login。脚本实际做了以下四件事对应 release.sh 的源码# 1. 用 sed 将 Cargo.toml 中的 version 字段替换为目标版本号 sed -i.old -e s/^version .*$/version \${THRIFT_RELEASE_VERSION}\/g Cargo.toml rm Cargo.toml.old # 2. 提交 Cargo.toml 的版本变更 git add Cargo.toml git commit -m Update thrift crate version to ${THRIFT_RELEASE_VERSION} -m Client: rs # 3. 清理并打包 cargo clean cargo package # 4. 发布 cargo publish注意脚本头部还启用了set -o errexit、set -o pipefail、set -o nounset三个严格模式任何一步失败都会立即中止避免在打包失败后仍继续执行发布这是一个很实用的安全设计。路径 B手动发布七步走如果你希望完全掌控每个环节可以按照 RELEASING.md 的 Manual 步骤逐步操作Step 1更新版本号编辑 lib/rs/Cargo.toml将version 1.0键改为目标版本号例如[package] name thrift description Rust bindings for the Apache Thrift RPC system edition 2021 version 0.21.0 license Apache-2.0Step 2提交版本变更git add Cargo.toml git commit -m Update thrift crate version to [THRIFT_RELEASE_VERSION] -m Client: rsStep 3登录 crates.iocargo login如果你的凭证已保存在~/.cargo/credentials这一步可以跳过。Step 4清理构建产物cargo cleanStep 5打包关键校验环节cargo package这一步是发布流程中最容易踩坑的环节。cargo package在任何未提交uncommitted或未忽略ignored文件存在时都会失败。官方明确警告不要使用--allow-dirty标志绕过校验正确做法是把这些文件加入 Cargo.toml 的exclude键让 cargo 在打包时主动忽略它们。当前仓库的 Cargo.toml 就是一个现成的范例exclude [Makefile*, test/**, *.iml]这里排除了Makefile系列文件、test测试目录和 IntelliJ 项目文件*.iml它们不应进入 crates.io 发布的包体。如果你新增了其他本地文件导致cargo package报错就应仿照此格式把它们追加到exclude列表。Step 6发布cargo publish发布成功后thriftcrate 的新版本即出现在 crates.io其他项目即可在Cargo.toml中通过thrift x.y.z依赖该版本其中x.y.z应对应你使用的 Thrift 编译器版本详见 lib/rs/README.md。源码视角发布链路中的三个关键设计1.Cargo.toml的 feature 与依赖决定了发布包的能力边界lib/rs/Cargo.toml 中定义了 crate 的依赖与特性开关[dependencies] byteorder 1.3 integer-encoding 3.0.3 uuid 1 log {version 0.4, optional true} ordered-float 3.0 threadpool {version 1.7, optional true} [features] default [server] server [threadpool, log]default特性默认启用server即默认引入threadpool与log依赖仅需客户端能力的使用方可通过default-features false关闭服务端相关依赖。ordered-float被显式 re-export见 lib/rs/src/lib.rs因为代码生成器会用到该类型这是发布包需要向消费者暴露的关键实现细节。从源码结构看crate 内部模块划分为protocol、transport、server受serverfeature 控制见 lib/rs/src/lib.rs、errors与autogen五层发布前应确认这些模块在当前版本号下行为一致。2. Rust 代码生成器与运行时库必须版本对齐thriftcrate 与 Thrift 编译器的 Rust 代码生成器 compiler/cpp/src/thrift/generate/t_rs_generator.cc 是配套发布的。发布新版本前需要确保生成器生成的代码autogen层与运行时库 API 相互兼容——这也是 lib/rs/README.md 强调crate 版本应与 Thrift 编译器版本对应的原因。README 中的 Breaking Changes 记录如 0.15.0 移除Error.description()、0.13.0 改用 std 的TryFrom等都是这类版本对齐影响使用方的实例。3. 仓库构建系统对发布质量的隐性约束lib/rs/Makefile.am 将release.sh与RELEASING.md一并列入EXTRA_DIST随源码分发的文件清单确保发布脚本与文档始终随仓库源码一起分发。同时该文件定义的check-local目标给出了发布前的质量关卡check-local: $(CARGO) fmt --all -- --check $(CARGO) clippy --all -- -D warnings $(CARGO) test即代码格式检查cargo fmt、clippy 零警告-D warnings将警告升级为错误、单元测试全部通过。这意味着在动手发布之前仓库本身要求 crate 代码必须干净通过这三道检查发布版本的代码质量底线由此保障。常见问题与规避建议问题场景原因正确做法cargo publish报 401/认证失败未登录或 Token 未存入~/.cargo/credentials执行cargo login或按账户设置步骤将 Token 保存到凭证文件cargo package因脏文件失败存在未提交或未忽略文件追加到Cargo.toml的exclude键禁止使用--allow-dirty版本号被拒绝不符合语义化版本三段格式确保形如#.##.##如0.21.0发布的 crate 与编译器不匹配运行时库与 t_rs_generator.cc 生成代码不一致发布前同步验证生成器与库的兼容性并阅读 lib/rs/README.md 的 Breaking Changes总结Apache Thrift Rust crate 的发布流程可以浓缩为一次账户准备 版本号语义化校验 干净打包 cargo publish。自动化脚本 release.sh 将改版本号 → 提交 → 打包 → 发布四步串联适合日常发版手动七步流程则适合需要精细控制如处理exclude排除项的场景。无论走哪条路径发布前的cargo fmt/clippy/test质量关卡与cargo package的干净工作区校验都是不可跳过的安全网。如需进一步了解 crate 的模块划分、兼容性承诺与生成代码行为可继续阅读 lib/rs/README.md 与 lib/rs/src/lib.rs。【免费下载链接】thriftApache Thrift项目地址: https://gitcode.com/gh_mirrors/thrift2/thrift创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Apache Thrift Rust crate 发布指南：从 crates.io 账户配置到 `cargo publish` 全流程
Apache Thrift Rust crate 发布指南从 crates.io 账户配置到cargo publish全流程【免费下载链接】thriftApache Thrift项目地址: https://gitcode.com/gh_mirrors/thrift2/thriftApache Thrift 的 Rust 运行时库thriftcrate位于 lib/rs 目录是构建 Thrift 客户端与服务端的基础依赖其发布流程由 RELEASING.md 正式定义。本指南完整讲解该 crate 的发布操作一次性配置 crates.io 账户、语义化版本号要求、自动化脚本发布与手动发布两种路径并结合仓库中的 release.sh、Cargo.toml 与构建脚本源码说明每一步背后的原理与常见坑点。读完后你将能独立完成一次 Apache Thrift Rust crate 的版本发布。发布总览两大步骤发布thriftcrate 的整体流程并不复杂分为两个主要阶段设置 crates.io 账户一次性——准备用于发布包的身份凭证与 API Token打包并发布 crate 本体——更新版本号、校验打包内容、执行cargo publish。其中第二阶段既可以通过仓库自带的自动化脚本 release.sh 一键完成也可以按手册逐步操作。下文先讲一次性账户准备再分别展开自动化与手动两种发布路径。第一步一次性设置 crates.io 账户发布 crate 前需要先在 crates.io 上完成身份配置该步骤只需执行一次打开 crates.io 站点点击右上角Log In按钮登录。务必使用对 thrift 仓库拥有写权限的 GitHub 账号登录——crates.io 通过 GitHub OAuth 关联身份发布权限与仓库权限直接挂钩。点击右上角的用户头像按钮选择Account Settings账户设置。在API AccessAPI 访问区域点击New Token生成一个新的 API Key。这是cargo向 crates.io 发布包时使用的凭证。生成的 API Key 需要妥善保存。如果你只打算用这个 GitHub 账号向 crates.io 发布 crate可以按照 crates.io 页面提示将生成的 Key 保存到~/.cargo/credentials文件中。该文件是 cargo 的全局凭证存储位置保存后cargo publish将自动读取无需每次手动cargo login。第二步发布前必须明确的版本号规则在执行任何发布操作前请先确认版本号格式。cargo要求 crate 版本号遵循**语义化版本Semantic Versioning**规范THRIFT_RELEASE_VERSION必须包含 major、minor 与 patch 三个数字段即必须形如#.##.##例如0.21.0。这一点在仓库中是有硬性校验的。release.sh 的脚本开头就使用正则^0-9{2}$校验入参不符合该格式会直接打印用法说明并退出if ! [ $# -eq 1 $1 ~ ^[0-9{2}$ ]]; then (2 echo Usage: ./publish-crate.sh [THRIFT_RELEASE_VERSION] ) (2 echo THRIFT_RELEASE_VERSION is in semantic versioning format, i.e. #.##.##) exit 1 fi以当前仓库 lib/rs/Cargo.toml 为例crate 版本为0.21.0这是符合语义化版本三段的典型示例。路径 A自动化发布仓库在 lib/rs 目录下提供了发布脚本 release.sh只需一条命令即可完成从改版本号到发布的全过程./release.sh [THRIFT_RELEASE_VERSION]前提条件使用自动化脚本要求你已将 crates.io 的 API Token 存入~/.cargo/credentials因为脚本内部不会再执行交互式的cargo login。脚本实际做了以下四件事对应 release.sh 的源码# 1. 用 sed 将 Cargo.toml 中的 version 字段替换为目标版本号 sed -i.old -e s/^version .*$/version \${THRIFT_RELEASE_VERSION}\/g Cargo.toml rm Cargo.toml.old # 2. 提交 Cargo.toml 的版本变更 git add Cargo.toml git commit -m Update thrift crate version to ${THRIFT_RELEASE_VERSION} -m Client: rs # 3. 清理并打包 cargo clean cargo package # 4. 发布 cargo publish注意脚本头部还启用了set -o errexit、set -o pipefail、set -o nounset三个严格模式任何一步失败都会立即中止避免在打包失败后仍继续执行发布这是一个很实用的安全设计。路径 B手动发布七步走如果你希望完全掌控每个环节可以按照 RELEASING.md 的 Manual 步骤逐步操作Step 1更新版本号编辑 lib/rs/Cargo.toml将version 1.0键改为目标版本号例如[package] name thrift description Rust bindings for the Apache Thrift RPC system edition 2021 version 0.21.0 license Apache-2.0Step 2提交版本变更git add Cargo.toml git commit -m Update thrift crate version to [THRIFT_RELEASE_VERSION] -m Client: rsStep 3登录 crates.iocargo login如果你的凭证已保存在~/.cargo/credentials这一步可以跳过。Step 4清理构建产物cargo cleanStep 5打包关键校验环节cargo package这一步是发布流程中最容易踩坑的环节。cargo package在任何未提交uncommitted或未忽略ignored文件存在时都会失败。官方明确警告不要使用--allow-dirty标志绕过校验正确做法是把这些文件加入 Cargo.toml 的exclude键让 cargo 在打包时主动忽略它们。当前仓库的 Cargo.toml 就是一个现成的范例exclude [Makefile*, test/**, *.iml]这里排除了Makefile系列文件、test测试目录和 IntelliJ 项目文件*.iml它们不应进入 crates.io 发布的包体。如果你新增了其他本地文件导致cargo package报错就应仿照此格式把它们追加到exclude列表。Step 6发布cargo publish发布成功后thriftcrate 的新版本即出现在 crates.io其他项目即可在Cargo.toml中通过thrift x.y.z依赖该版本其中x.y.z应对应你使用的 Thrift 编译器版本详见 lib/rs/README.md。源码视角发布链路中的三个关键设计1.Cargo.toml的 feature 与依赖决定了发布包的能力边界lib/rs/Cargo.toml 中定义了 crate 的依赖与特性开关[dependencies] byteorder 1.3 integer-encoding 3.0.3 uuid 1 log {version 0.4, optional true} ordered-float 3.0 threadpool {version 1.7, optional true} [features] default [server] server [threadpool, log]default特性默认启用server即默认引入threadpool与log依赖仅需客户端能力的使用方可通过default-features false关闭服务端相关依赖。ordered-float被显式 re-export见 lib/rs/src/lib.rs因为代码生成器会用到该类型这是发布包需要向消费者暴露的关键实现细节。从源码结构看crate 内部模块划分为protocol、transport、server受serverfeature 控制见 lib/rs/src/lib.rs、errors与autogen五层发布前应确认这些模块在当前版本号下行为一致。2. Rust 代码生成器与运行时库必须版本对齐thriftcrate 与 Thrift 编译器的 Rust 代码生成器 compiler/cpp/src/thrift/generate/t_rs_generator.cc 是配套发布的。发布新版本前需要确保生成器生成的代码autogen层与运行时库 API 相互兼容——这也是 lib/rs/README.md 强调crate 版本应与 Thrift 编译器版本对应的原因。README 中的 Breaking Changes 记录如 0.15.0 移除Error.description()、0.13.0 改用 std 的TryFrom等都是这类版本对齐影响使用方的实例。3. 仓库构建系统对发布质量的隐性约束lib/rs/Makefile.am 将release.sh与RELEASING.md一并列入EXTRA_DIST随源码分发的文件清单确保发布脚本与文档始终随仓库源码一起分发。同时该文件定义的check-local目标给出了发布前的质量关卡check-local: $(CARGO) fmt --all -- --check $(CARGO) clippy --all -- -D warnings $(CARGO) test即代码格式检查cargo fmt、clippy 零警告-D warnings将警告升级为错误、单元测试全部通过。这意味着在动手发布之前仓库本身要求 crate 代码必须干净通过这三道检查发布版本的代码质量底线由此保障。常见问题与规避建议问题场景原因正确做法cargo publish报 401/认证失败未登录或 Token 未存入~/.cargo/credentials执行cargo login或按账户设置步骤将 Token 保存到凭证文件cargo package因脏文件失败存在未提交或未忽略文件追加到Cargo.toml的exclude键禁止使用--allow-dirty版本号被拒绝不符合语义化版本三段格式确保形如#.##.##如0.21.0发布的 crate 与编译器不匹配运行时库与 t_rs_generator.cc 生成代码不一致发布前同步验证生成器与库的兼容性并阅读 lib/rs/README.md 的 Breaking Changes总结Apache Thrift Rust crate 的发布流程可以浓缩为一次账户准备 版本号语义化校验 干净打包 cargo publish。自动化脚本 release.sh 将改版本号 → 提交 → 打包 → 发布四步串联适合日常发版手动七步流程则适合需要精细控制如处理exclude排除项的场景。无论走哪条路径发布前的cargo fmt/clippy/test质量关卡与cargo package的干净工作区校验都是不可跳过的安全网。如需进一步了解 crate 的模块划分、兼容性承诺与生成代码行为可继续阅读 lib/rs/README.md 与 lib/rs/src/lib.rs。【免费下载链接】thriftApache Thrift项目地址: https://gitcode.com/gh_mirrors/thrift2/thrift创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考