无论是库还是大型应用程序，这都没有太大关系。语义化版本控制方案对大型应用程序来说非常适用。它甚至可以用于捆绑成一个平台的应用程序集合，但在这里，它会变得相当难以处理。
主要问题在于，你是否会采取在一个版本中支持弃用，而只在下一个主版本中移除它的路线。拥有已弃用但受支持的功能可能会花费相当多的精力。当你将要更改持久化数据模型时，弃用通常会变得不可能。如果发生这种情况，你甚至不能进行带有弃用功能的次要版本更新，并且会立即跳转到下一个主版本。这正是大型应用程序通常遇到的问题。你从 3.0.0 变为 3.0.1 再变为 4.0.0，因为你无法提供向后兼容性。如果你经常有破坏性更改，坚持使用 semver 的价值很小。
话虽如此，我更喜欢这种结构，因为它能更清晰地向开发人员传达将会有破坏性更改。YYYY.N 方案对我这个开发者来说毫无意义，对我这个管理员来说也毫无意义。
那么问题是，你想通过版本传达什么？如果你想进行 6 次功能发布（可能包含破坏性更改，也可能不包含），并且每第 6 次发布将获得更长的补丁支持；并且你不想为补丁发布进行版本控制。那么 X.Y 是一个合适的方案，其中 Y=0 是获得更长支持的版本。X 只是一个数字。问题在于，当 X 是年份时，Y 很快就会与月份相关联。那么更新的、获得更长支持的版本将在 1 月发布？我总是不得不查找哪个 Ubuntu 版本是 LTS 版本，这让我很烦恼。
那么，如果 Discourse 只是继续使用当前的主版本呢？下一个获得更长支持的版本称为 4.0；然后我们得到 4.1 到 4.5 作为功能发布；之后是 5.0，这是最新的、获得更长支持的版本。
这样，你就不会遇到因重大问题而导致发布延迟的尴尬时刻。
你可以选择添加一个“补丁”号，如果你计划明确发布补丁（而不是进行滚动补丁发布）。“但那样就有 x.y.z，这看起来像 semver”。嗯，不是的，它看起来像 semver，但实际上不是。每一个新的“次要”版本都可能是破坏性的。所以我建议只坚持使用 X.Y 作为版本方案，其中 Y=0 表示 LTS。
版本字符串暂且不论。我确实喜欢新的发布计划。