我正在为我的项目使用替代版本编号方法。我遇到了cabal和stack的奇怪行为，这使我无法充分享受这种方法的好处。cabal和stack都强制版本格式为Int。Int.Int，这不包括我用于分支的其他版本格式(0.x.x、1.x.x、1.0.x等)的情况。
如果我的.cabal文件中有第version: 0.x.x行，则在运行cabal build时出现Parse of field 'version' failed.错误，在运行stack init时出现Unable to parse cabal file {PROJECT_NAME}.cabal: NoParse "version" 5错误。
有没有办法禁用cabal和stack命令的版本解析？有旗帜吗？还是我必须向cabal和stack的开发人员请求这种更改(添加标志，禁用版本解析)？
为什么要进行任何解析？它如何帮助构建包？cabal或stack是否会自动增加某些事件的内部版本号？如果是，我在哪里可以阅读更多关于这个的信息？我如何影响在cabal和stack中实现版本编号增量的方式？我希望Haskell软件包的开发人员考虑到替代版本编号方法的可能性。
附言。对于所有感兴趣的人，我想快速总结一下"奇怪"版本号背后的想法，例如0.x.x、1.x.x、1.0.x。我使用带有x的版本号来描述允许代码更改的开发流线型，而1.0.0、1.1.0、2.35.46等版本号用于描述开发的冻结状态(准确地说，它们用于软件的发布版本)。请注意，诸如0.x.0、1.x.152.x.23这样的版本号也是可能的(用于软件的快照/构建)，它们意味着代码库已经继承自版本号分别为0.x.x、1.x.x和2.x.x的分支。
为什么我需要0.x.x、1.x.x和2.x.x这样的版本号？简而言之，不同数量的x意味着不同类型的分支。例如，版本号模式N.x.x用于支持分支，而模式N.M.x用于发布分支。支持分支背后的想法是，由于相应代码库的不兼容，它们被创建。由于相应代码库中的功能冻结而创建发布分支。例如，分支1.0.x、1.1.x、1.2.x、...由于分支1.x.x中的功能冻结(或发布)而创建。
我知道这一切都令人困惑，但我努力建立这种版本编号方法，并通过我的演示文稿和其他项目继续致力于了解版本编号的不一致。一旦您更多地考虑了 semver 方法的陷阱，这一切都是有意义的(您可以在链接下方找到有关此事的详细幻灯片共享演示文稿)。但我现在不想为它辩护。目前，我只是希望cabal和stack停止在我的项目中执行他们认为不合理的规则。希望你能帮到我。
你不能。版本将被解析为Version，即：
data Version = PV0 {-# UNPACK #-} !Word64
| PV1 !Int [Int]
Stack 使用 Cabal 作为库，但有自己的Version类型：
newtype Version =
Version {unVersion :: Vector Word}
deriving (Eq,Ord,Typeable,Data,Generic,Store,NFData)
阴谋集团和堆栈都没有办法自定义解析。如果要使用其他版本类型，则必须编写这些程序的自己的变体。但话又说回来，在这一点上你并没有赢得任何东西：Hackage和Stackage都不会识别你的软件包的版本。
因此，目前无法1.x.x。您可以与99999999或类似的东西交换x来缓解问题。话虽如此，目前尚不清楚cabal install应该安装什么。99999999版本？还是最新的稳定变体？
如果你可以表达语义，那么在邮件列表上的讨论以及功能请求可能会在(遥远的)将来改变行为，但现在，你要么必须自己修补程序，要么使用其他编号方案。
有没有办法禁用对阴谋集团和堆栈命令的版本解析？有旗帜吗？
不。
还是我必须向
cabal和stack的开发人员请求这种更改(添加标志、禁用版本解析)？
你当然可以问，但有很多悬而未决的问题，你不太可能得到任何牵引力。你必须非常有说服力 - 足以推翻20多年的经验，这些经验表明当前的版本控制方案基本上是可行的。实际上，如果您希望发生这种情况，您可能必须自己维护这些工具的分支，并提供使用此方案托管包的替代位置。
为什么要进行任何解析？它如何帮助构建包？
包指定依赖项，并为每个依赖项指定它们使用的版本范围。然后，生成工具使用约束求解器选择一组连贯的包/版本对来满足所有(传递)依赖项。为此，他们必须至少能够检查给定版本是否在给定范围内 - 这需要至少解析版本号一点点。
阴谋集团或堆栈会自动增加某些事件的内部版本号吗？如果是，我在哪里可以阅读更多关于这个的信息？
没有什么是自动的。但是你应该看看软件包版本政策，它是软件包维护者之间的社会契约。它让一个软件包维护者说，"我正在使用bytestring版本0.10.0.1它似乎可以工作。我小心翼翼地确定我所有bytestring进口的资格;因此，我可以指定一个像>=0.10 && <0.11这样的范围，并确保一切正常，同时让bytestring维护者能够向我的用户推送安全性和效率更新。 而不必仔细阅读bytestring的完整文档，并希望其维护者已经写过他的版本号的含义。
我如何影响在阴谋集团和堆栈中实现版本编号增量的方式？
与您之前关于改变社区做事方式的问题一样，我认为对包版本控制策略的修改将非常困难，尤其是您在这里提出的激进更改。变革越激进，就越需要谨慎的动机才能获得牵引力。
老实说，我不知道采取这种动机和讨论的合理地方是什么;也许是哈斯克尔咖啡馆的邮件列表或类似的。