作为经常折腾Hackage、跟Cabal和PVP打交道的Haskell开发者，我太懂你纠结预发布版本号的痛点了！你提到的两个方案确实都有明显问题，咱们来聊聊Haskell社区里最常规、也符合PVP规范的做法：

首先先确认你踩的坑没错：

• 带字符串后缀（比如0.0.0.1-alpha）的版本号确实违反PVP——PVP明确要求版本号组件必须是数字，现在Cabal已经不支持这种带标签的版本号，部分工具甚至会直接报错，绝对不能用。
• 靠0.*系列来标记不稳定阶段也有坑：一是没法处理1.x稳定版之后的预发布（比如2.0的RC），二是其他生态（比如Rust）的开发者会误以为0.*是稳定版（毕竟Rust的0.x可以是稳定的），哪怕加了README提示，也不如版本号本身直观。

那正确的做法分两种场景：

1. 1.0正式版之前的预发布 #

对于还没到1.0的项目，PVP本身就默认0.x系列的API是不稳定的，所以我们可以利用版本号的后几位来区分Alpha/Beta/RC阶段，比如：

• 0.0.1.0：第一个Alpha版本（基础功能实现，可能有很多bug）
• 0.0.1.1：Alpha 2（修复Alpha 1的bug，不新增功能）
• 0.0.2.0：Beta 1（核心功能全部实现，开始测试兼容性）
• 0.0.3.0：RC 1（功能冻结，只修复严重bug，接近正式版）
• 最终正式版：1.0.0.0

你也可以约定更清晰的规则，比如用第三位来标记阶段：第三位为0是Alpha，1是Beta，2是RC，比如0.1.0.0（Alpha）、0.1.1.0（Beta）、0.1.2.0（RC），团队内部统一就行。

2. 1.x稳定版之后的预发布（比如要发2.0的RC） #

这种情况不能用0.*了，我们可以用比正式版小一个次版本号的系列来标记预发布，比如要发2.0的正式版：

• 1.9.0.0：RC 1（API已经和2.0一致，功能冻结）
• 1.9.1.0：RC 2（修复RC1的bug）
• 正式发布后直接用2.0.0.0

这个做法完全符合PVP规范：1.9.x和2.0.x属于不兼容的版本组，依赖管理工具会正确识别这是一个过渡版本，不会和稳定的1.x系列混淆，Haskell社区里很多知名库都是这么干的。

最后补充：别忘文档提示 #

不管用哪种版本号规则，一定要在README的最顶部、Hackage包描述里明确标注当前版本的阶段——比如“⚠️ 这是Alpha版本，API可能随时变更，请勿用于生产环境”或者“✅ 当前是Release Candidate，功能已冻结，仅修复严重bug”，双保险避免误解。

备注：内容来源于stack exchange，提问作者Naitik Mundra