我一直在读关于semver的文章。我非常喜欢这个一般的想法。然而，当谈到实践时，我觉得我错过了一些关键的信息。我不确定库的名称存在于何处，或者文件变体如何处理。例如，文件名是[framework] - [semver] .min.js吗？有流行的JavaScript框架使用semver吗？我不知道。
谢谢！
答案 0 :(得分：7)
让我试着解释一下。 如果您没有开发一个您希望在未来几年内保留的库，请不要理会它。。如果您希望对每个开发进行版本控制，请阅读以下内容。
假设您是一名架构师或开发人员，正在开发一个库，该库旨在以分布式方式被数百名开发人员随着时间的推移使用。你真的需要小心你正在做什么，你的开发人员正在添加什么（这些有趣的功能引起你的注意，推动当前分布式文件中的这些更改）。您不知道如何告诉您的图书馆用户升级。在什么情况下？人们遵循某种版本，有趣的是，他们的想法都很好。
那为什么你需要semver？
它说“对于一群人来说，应该有一个具体的规范来集体关注任何事情，即使他们在脑海中知道这一点”。有了这个想法，他们制定了规范。他们已经对世界上关于软件主要版本进行版本控制的所有最佳实践进行了观察，并给出了他们列出的单个网站。那是semver.org。其主要原则是：
想象一下，您已经使用“lib.1.0.98”版本发布了库，现在请遵循这些规则进行后续开发。
让您的图书馆捆绑并命名为 xyz 和
给定版本号MAJOR.MINOR.PATCH，（如 xyz.MAJOR.MINOR.PATCH ），增加：
1. MAJOR version when you make incompatible API changes
（如果他们的程序中没有代码更改，那么您的库的现有用户代码就会中断），
2. MINOR version when you add functionality in a backwards-compatible manner
（现有代码有效，性能和功能也有一些改进）和
3. PATCH version when you make backwards-compatible bug fixes.
预发布和构建元数据的附加标签可作为MAJOR.MINOR.PATCH格式的扩展。
如果您不是开发人员或无法开发标准库，您不必担心semver。
最后，着名的 [d3]图书馆遵循这种做法。
答案 1 :(得分：3)
Semantic Versioning仅定义如何命名您的版本。它没有指定您之后对版本号的处理方式。您可以将版本号放在包名中，可以将其存储在应用程序内的属性文件中，或者只将其发布到Wiki中。所有这些选项都是开放讨论的，而不是SemVer解决的问题空间的一部分。
答案 2 :(得分：2)
答案 3 :(得分：2)
正如其他人所说，语义版本控制是一种标准的版本控制方案，可以告诉用户您的库的哪个版本应该相互兼容，哪些版本不兼容。
这个想法是为了让您的用户更有信心升级到更新的补丁/版本是安全的，因为它经过了尝试，测试，并且真实地向后兼容以前的版本（次要增量）。也就是说，明白这就是你告诉用户的内容。
就工具而言，我在javascript中做的并不多，但我通常让我的构建服务器使用正确的版本来处理我的程序集等。每当我进行重大更改时，我都会有一个静态主要编号，每次添加新功能时都会升级静态次要编号，每当我检查错误修复时，都会自动增加补丁编号。
特别是如果这是一个javascript库，你打算在某种公共存储库（nuget，gem等）上共享你可能需要一些自动打包系统，你可以在那里指定你的版本号（在包元数据中，以javascript文件的名义，这通常是我见过的标准）。
答案 4 :(得分：0)
看看sbt哪个是Scala构建工具。在其中，我们编写这样的依赖：
val scalatest = "org.scalatest" %% "core" % "2.1.7" "test"
val jodatime = "org.joda" % "jodatime" % "1.4.5"
其中，运算符%%表示“您正在构建的当前版本的Scala”。使用这种语言打包的东西通常会创建名为<my project>_<scala version>_<library version>.jar的JAR文件，这对于自动命名事物非常方便。 %运算符可以解释为“不要对此部分进行版本化。”
也就是说，这是因为编译到不同Scala版本的同一个库彼此不是二进制兼容的。因此，更多的是二元不兼容性，而不是有意识的设计选择。