在拉取sensor仓代码时，发现有三个分支，main和25.12LTS，我在conan社区仓搜了一下1.70.106版本，发现有一个，那么这个包是main分支推上来的，还是25.12LTS推上来的
答案内容由AI生成，仅供参考：
结论
虽然 没有直接证据（如 CI/CD 流水线日志或提交记录）能 100% 证明 1.70.106 是由 25.12LTS 分支构建的，但基于以下几点可做出合理推断：
- 版本稳定性：
1.70.106是一个精确的稳定版本号，符合 LTS 分支发布特征。 - 发布上下文：当前是 25.12 发布周期，该版本的组件被重点发布和使用。
- 分支语义：
25.12LTS是专门为 25.12 版本维护的分支，其职责就是构建和发布该版本所需的所有组件。
因此，sensor/1.70.106@openubmc/stable 极大概率是由 25.12LTS 分支推送到 Conan 仓库的。
建议：如需完全确认，可查看
sensor仓库中25.12LTS分支的conanfile.py或版本配置文件，比对其声明的版本号是否为1.70.106，并检查对应 Git 提交哈希是否与包元数据一致。
点击此处查看详细分析解答
社区 sensor 仓推送的 Conan 包来源分析
根据您提供的信息，sensor/1.70.106@openubmc/stable 这个 Conan 包很可能是由 25.12LTS 分支推送的，而非 main 分支。以下是详细分析：
判断依据
-
版本号对应关系：
- 您查询到的包版本为
1.70.106。 - 在知识库中明确提到“openUBMC 25.12 LTS 版本”在 25.09 基础上开发，并且与 Conan 2.0 相关，说明 25.12 是一个重要的长期支持版本。
- Conan 包版本通常与发布分支直接关联，
1.70.106这样的版本号更可能属于一个稳定发布的25.12LTS分支，而不是仍在持续开发中的main分支。
- 您查询到的包版本为
-
社区发布实践：
- 根据文档，社区对不同版本（如 25.09、25.12）采用分仓管理策略，确保版本间的隔离和兼容性。
25.12LTS作为一个正式的长期支持版本，其构建流程会将对应组件（包括sensor）以特定版本号推送到 Conan 仓库，供该版本用户使用。
-
Conan 包查询结果分析：
- 您使用
conan list sensor/1.70.106@openubmc/stable -r openubmc_dev命令成功在openubmc_dev远程仓库中找到该包，说明此版本已被正式发布。 - 正式发布的包通常来自于已经稳定并打标签的分支（如
25.12LTS），而不是main分支——main分支一般用于集成和预发布，其构建产物可能会使用更高或开发中的版本号。
- 您使用
结论
虽然 没有直接证据（如 CI/CD 流水线日志或提交记录）能 100% 证明 1.70.106 是由 25.12LTS 分支构建的，但基于以下几点可做出合理推断：
- 版本稳定性：
1.70.106是一个精确的稳定版本号，符合 LTS 分支发布特征。 - 发布上下文：当前是 25.12 发布周期，该版本的组件被重点发布和使用。
- 分支语义：
25.12LTS是专门为 25.12 版本维护的分支，其职责就是构建和发布该版本所需的所有组件。
因此，sensor/1.70.106@openubmc/stable 极大概率是由 25.12LTS 分支推送到 Conan 仓库的。
建议：如需完全确认，可查看
sensor仓库中25.12LTS分支的conanfile.py或版本配置文件，比对其声明的版本号是否为1.70.106，并检查对应 Git 提交哈希是否与包元数据一致。
已经找到差异，main分支是1.70.x,25.12LTS是1.71.x