最佳实践：软件版本控制

Question

最佳实践：软件版本控制

versioning

211

有没有关于如何为你在业余时间开发的仅供娱乐但将被某些人使用的软件进行版本控制的指南或标准最佳实践？我认为有必要对这种软件进行版本控制，以便您知道正在谈论的版本（例如用于修复错误、支持等）。

但是我应该从哪里开始进行版本控制呢？0.0.0？还是0.0？然后我该如何增加这些数字？主要版本.次要更改？每次提交到版本控制系统都应该是另一个版本吗？还是只针对在生产环境中使用的版本？

- RoflcoptrException

2

你的源代码控制工具是干什么用的？你必须使用一个。你在使用哪个？ - S.Lott

3

我有点晚了...不过这个链接是 https://dev59.com/OHRB5IYBdhLWcg3weHHx 的复制。 - derivation

12

SemVer是一个版本控制系统，旨在通过清晰、简洁的规则来定义软件库版本号。每个版本号由三个数字组成：主版本号、次版本号和补丁号。这三个数字都是非负整数，版本号必须按照从左到右递增的方式进行指定。主版本号的变化表示向后不兼容的API修改，次版本号的变化表示向后兼容的功能性新增，而修订号的变化表示向后兼容的问题修复。此外，版本号还可以包括一个可选的预发布标识符和元数据。SemVer的规则是为了确保开发人员和用户能够轻松地理解软件库版本之间的区别，并确定何时需要更新其依赖关系。它已被广泛采用，包括npm、RubyGems和Docker等流行的软件包管理器和应用程序。 - Dave Gregory

1

@DaveGregory对这个问题给出了一个非意见性的答案。该链接semver.org详细描述了版本控制语义。大多数Google项目，包括Android，都使用相同的方案。此外，在Tom Preston-Werner身上，我们可以找到任何关于这个主题的可信声音。 - Rahul Murmuria

12个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Amandeep Kirar · Answer 1

我们采用a.b.c的方法，如下所示：

如果应用程序发生了重大变化，例如我们将.NET 1.1应用程序升级到.NET 3.5，则增加“a”。

如果有任何新的CR或增强功能被实现，那么增加“b”。

如果代码中有缺陷修复，则增加“c”。请注意保留HTML标签。

- rwheadon · Answer 2

我从最低的（非热修复）段开始版本控制。我不限制这个段落为10。除非你正在跟踪构建，否则你只需要决定何时应用增量。如果你有一个QA阶段，那么可能是在通过QA并发布后对最低段应用增量，然后对下一个段进行增量。将最上面的段留给主要的行为/UI更改。

如果你像我一样，你会将它变成方法的混合，以匹配你的软件进展的步伐。

我认为最被接受的模式是a.b.c.或a.b.c.d，特别是如果你在QA/Compliance中使用。我曾经因为日期是版本的常规部分而遭受了很多抨击，所以我放弃了它。

我不跟踪构建，所以我喜欢使用a.b.c模式，除非涉及到热修复。当我必须应用热修复时，我将参数d作为带时间的日期应用。我将时间参数采用d，因为在生产中真正爆发时，可能会有几个时间点。我只在我为生产修复而分支时应用d段（YYYYMMDDHHNN）。

个人而言，我不反对使用 va.b revc 的软件方案，其中 c 是 YYYYMMDDHHMM 或 YYYYMMDD。

话虽如此。如果你可以获取一个工具来配置和运行，那么你就可以避免头痛的版本控制意见方面的问题，而且你只需要说“使用这个工具”... 因为开发过程中的每个人通常都是非常顺从的。