如何管理/控制软件版本？

Question

我面临一个问题，要为我的公司已经存在的几个软件部件创建一个版本控制大纲。到目前为止，没有人知道有不同的版本--对开发人员的期望--这就是制定大纲的原因。事实上，我应该建立未来的版本控制并与我们的管理层沟通.

因此，问题是如何创建这样一个大纲。是否有需要遵循的原则使软件版本控制更容易，或者甚至是一个很好的程序来映射所有版本和兼容性？

是否有好的方法来控制软件版本？

Answer 1

看看语义版本化。

在软件管理的世界里，有一个可怕的地方叫做“依赖地狱”。您的系统越大，集成到软件中的包越多，您就越有可能发现自己有一天会陷入绝望的深渊。在有许多依赖项的系统中，发布新的包版本很快就会变成一场噩梦。如果依赖规范太紧，您将面临版本锁定的危险(无法升级包而不需要发布每个依赖程序包的新版本)。如果过于松散地指定依赖项，那么您将不可避免地被版本的杂乱无章(假设与更多的未来版本兼容而不是合理)所咬伤。依赖地狱是当版本锁定和/或版本混杂阻止您轻松和安全地向前推进项目时所处的位置。作为这个问题的解决方案，我提出了一组简单的规则和要求，这些规则和要求决定版本号是如何分配和递增的。我称这个系统为“语义版本控制”。在此方案下，版本号及其更改方式传达了底层代码的含义，以及从一个版本修改到下一个版本的含义。

Answer 2

我不知道这方面的规则，但在很多情况下，版本是由2-4个数字组成的。

像1.2.3.4这样的版本可以解释为

• 1-主要版本，更改它将破坏兼容性。
• 2-次要版本，新功能
• 3-修复版本，只有当发行版包含bugfix时
• 4.构建数，即构建的内部数量，通常由自动构建系统或连续集成系统决定。

正如我所提到的，这只是许多常见的解决办法之一，而这正是我所希望的。

Answer 3

嗯，如果你还没有这么做，你真的需要使用版本控制软件。我知道化石有很好的内部显示分支和合并。Git和Mercurial现在很热，但是Subversion可能仍然是最受欢迎的，因为它已经存在更久了。我敢打赌，Git的插件可以根据软件历史制作图形并执行分析。

当您第一次将软件放入源代码管理中时，您可能希望重新创建主要版本的历史。想必(希望，如“请上帝，请”)，他们有每个主要版本的源代码压缩文件。您可以解压缩这些文件，并按时间顺序将包含的文件签入源代码管理。然后，您就有了分支和合并的历史以及主要的功能，您可以在Git或Mercurial插件中使用这些功能来生成漂亮的图形。

可能需要几次尝试才能得到最初的签入--非常正确。我无法想象，在没有源代码管理的情况下，您有不止一个开发人员在做一些事情。您目前使用的是什么？