Kanidm项目支持与版本发布策略详解
项目地址: https://gitcode.com/gh_mirrors/ka/kanidm 项目概述
Kanidm是一个现代化的身份管理系统，采用Rust语言开发，提供安全、高效的目录服务功能。本文将深入解析Kanidm项目的版本发布策略和支持政策，帮助用户理解如何规划系统升级和维护。
版本发布周期
Kanidm采用季度发布模式，每年固定发布四个版本：
- 2月1日
- 5月1日
- 8月1日
- 11月1日
这种固定的发布周期为系统管理员提供了可预测的升级计划，便于提前规划系统维护工作。
版本号规范
Kanidm遵循语义化版本控制规范（SemVer），采用主版本号.次版本号.修订号的格式，可选添加-标签：
- 开发分支：
X.Y.Z-dev - 预发布分支：
X.Y.Z-pre - 稳定分支：
X.Y.Z
在正式发布前7天，项目团队会创建发布分支并打上预发布标签。版本发布流程通过Git分支管理清晰可见，确保发布过程透明可控。
版本支持政策
Kanidm对稳定版本提供4个月的支持周期，这确保了新旧版本之间有1个月的重叠支持期。在支持期内，项目团队会提供以下类型的修复：
- 安全问题修复
- 可能导致数据丢失或损坏的缺陷修复
- 影响升级流程的问题修复
- 项目团队酌情决定的其他质量修复
建议生产环境始终跟踪最新的稳定分支，以获得最佳支持和安全性。
系统兼容性要求
复制拓扑要求
所有节点必须运行相同版本，拓扑结构中最多允许包含2个节点。这一限制确保了数据一致性和系统稳定性。
升级策略
Kanidm支持从当前稳定版本的前一个次版本直接升级。例如：
- 1.2.0版本可升级至1.3.0
- 1.2.0版本不可直接升级至1.4.0
这种策略确保了升级路径的可靠性，减少了跨版本升级可能带来的风险。
工具版本匹配
命令行工具(kanidm)和同步连接器(kanidm-ipa-sync, kanidm-ldap-sync)必须始终与服务器版本保持一致。这种严格的要求确保了各组件间的兼容性和功能完整性。
Unix客户端兼容性
服务器支持与比其低一个次版本的Unix客户端通信。例如：
- 1.4.0版本服务器支持1.4.0和1.3.0版本的Unix客户端工具
- 1.2.0及更低版本的Unix客户端工具将不被支持
API稳定性保证
Kanidm提供不同级别的API稳定性保证：
稳定API
以下API接口保证稳定性，仅在遇到伦理、安全或潜在数据损坏问题时才会做出破坏性变更：
- LDAP协议操作
- 使用
proto/src/v1元素的JSON HTTP端点
非稳定API
以下API接口不保证稳定性，变更将尽可能最小化：
kanidm_unixd解析器的Unix域套接字APIkanidmd服务器的Unix管理域套接字- Web用户界面设计和操作
- 条目模式(entry schema)
- 除非特别说明，否则所有Kanidm提供的CLI接口
- 使用
proto/src/internal.rs元素的JSON HTTP端点 proto/src/scim_v1的SCIM操作
废弃政策
功能或API将在提前一个发布周期通知后移除。所有废弃声明都会在发布说明中明确标注，为用户提供充足的迁移时间。
Python模块说明
Kanidm的Python模块通常滞后于核心Rust代码的功能变更，采用按需开发模式。项目鼓励社区贡献功能改进，所有代码变更都尽可能包含完整的类型转换支持。
特殊情况处理
在遇到不可预见或特殊情况时，项目团队保留做出与本文档相矛盾决策的权利。在此类情况下，团队将尽最大努力说明决策原因，并尽量减少对用户的影响。
通过理解这些支持政策和版本管理策略，系统管理员可以更好地规划Kanidm的部署和维护工作，确保系统稳定运行并获取持续支持。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
