我的公司正在开发一种产品。它将由 SVN 进行版本控制。这是一个网络应用程序，所以基本上永远不会有一个版本没有其中的某些功能，因此总是可以标记为测试版。但由于它将成为一种企业产品，我真的不希望出现“不稳定的警戒”。那么您将如何进行版本控制？1.0稳定吗？构建日期是否应该在版本号中？告诉我你们在想什么！
Thomaschaaf
问问题
59237 次
18 回答
265
[主要].[次要].[发布].[构建]
Major : 真正的营销决策。你准备好调用 1.0 版本了吗？公司是否认为这是客户可能需要支付更多费用的主要版本，还是当前主要版本的更新可能是免费的？与其说是研发决策，不如说是产品决策。
次要：每当主要增加时从 0 开始。每个公开的版本 +1。
release：每次你达到一个开发里程碑并发布产品时，即使是在内部（例如给 QA），都会增加它。这对于组织中团队之间的沟通尤为重要。不用说，永远不要发布相同的“发布”两次（即使是在内部）。在次要++ 或主要++ 时重置为 0。
build：可以是 SVN 版本，我觉得效果最好。
示例
我当前的 chrome：83.0.4103.61
于 2009-03-05T15:31:26.280 回答
71
xyzg
g 的增量是不稳定的。z 中的（或 RC）增量是稳定的并且意味着错误修复。
y 的增量是稳定的并且意味着新特征。
x 中的增量是稳定的主要版本，没有 100% 向后兼容性。
于 2009-03-05T15:24:53.517 回答
34
我曾经为我的一个大型项目写了一份详尽的“版本控制风格指南”。该项目未能实现，但样式指南仍可在线获取。这是我个人的看法，也许对你有帮助（或鼓舞人心）。
请注意，这是一个很长的文本，涉及到组件版本控制与产品版本控制之类的东西。也对一些在OSS社区流行的版本方案表达了强烈的意见，但是我有，所以表达出来。;-)
例如，我不同意使用 Subversion 修订号。您可能希望在继续在 TRUNK 中开发的同时维护已发布的版本，因此您将设置一个维护分支 - 并且您的修订号版本控制会付诸东流。
编辑：作为总结，它区分版本控制源文件、组件和整个产品。它对组件和产品使用单独的 xy 版本控制系统，两者之间具有很好的相互依赖关系，这使得跟踪哪个组件版本属于哪个产品版本变得微不足道。它还讨论了如何在不破坏系统的情况下处理 alpha/beta/release/patch 周期。实际上，这是整个开发周期的作案手法，因此您可能需要挑选。;-)
编辑 2：由于有足够多的人发现我的文章对使它成为“好答案”有用，我再次开始撰写这篇文章。PDF 和 LaTeX 版本现已推出，一旦我有时间，我会尽快进行完整的重写，包括更好的语言和解释性图形。感谢您的投票！
于 2009-03-05T15:26:26.120 回答
11
A B C D
增量：何时
-d ：错误修复-c
：维护，例如性能改进
-b ：新功能-a ：
架构更改
强制项是最左边的一项，例如，如果有新功能和修复的错误，那么您只需要增加b。
于 2014-12-18T17:16:31.130 回答
9
根据我在复杂的企业平台级依赖管理和发布版本控制方面的经验，我开始推荐一种我喜欢称之为半语义版本控制的方法。
基本上，它建立在Semantic Versioning 2.0之上，但并不那么严格。
半语义版本段：
<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]
主要发布段格式：
MARKETTING.MAJOR.MINOR.PATCH
每个段都应允许使用字母数字，但建议使用纯数字进行逻辑增量更改。
与 SemVer 一样，我建议使用Major、Minor 和 Patch 组件来表示反向兼容层，但我也建议在前面添加Marketing 组件。这允许产品所有者、功能史诗/组和业务关注点独立于技术兼容性关注点来影响主要组件。
与其他答案不同，我不建议将内部版本号附加到主要部分。相反，在“+”之后添加一个发布后段（例如：1.1.0.0+build.42）。SemVer 称之为构建元数据，但我认为 Post-Release Segment 更清晰。该段非常适合将后缀数据声明为与主要版本段中的兼容性信息无关. 然后可以为您的持续集成构建提供先前的版本号，并在每个主要版本之后重置一个增量构建号（例如：1.1.0.0 -> 1.1.0.0+build.1 -> 1.1.0.0+build.2 -> 1.1.0.1）。有些人交替喜欢将 svn 修订号或 git commit sha 放在这里，以便于绑定到代码存储库。另一种选择是将发布后部分用于修补程序和补丁，但可能值得考虑为此添加新的主要发布组件。当补丁组件增加时，它总是会被丢弃，因为版本是有效的左对齐和排序的。
除了发布和发布后段，人们通常希望使用预发布段来指示几乎稳定的预发布，如 alpha、beta 和候选发布。SemVer 方法效果很好，但我建议将数字组件与字母数字分类器分开（例如：1.2.0.0+alpha.2 或 1.2.0.0+RC.2）。通常，您会在添加发布后段的同时添加发布段，然后在下次添加主发布段时删除预发布段（例如：1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0)。添加预发布部分以表明发布版本即将发布，通常只是一组固定的功能，用于更深入的测试和共享，不会因更多的提交而每时每刻发生变化。
以涵盖几乎所有用例的方式对所有这些进行语义定义的美妙之处在于，您可以以标准方式解析、排序、比较和递增它们。当将 CI 系统用于具有大量独立版本化的小型组件（如微服务）的复杂应用程序时，这一点尤其重要，每个组件都有自己的托管依赖项。
如果你有兴趣，我用 ruby 写了一个半语义解析器。我不仅需要使用这种模式，还需要能够管理使用它的其他应用程序。
于 2014-07-18T06:00:32.557 回答
4
“版本号”是您内部版本控制系统的问题。版本号是另一回事（应该保持不同）。
坚持一个简单的 MAJOR.MINOR 发布系统（如 v1.27），其中 MAJOR 是兼容性级别（2.x 版与 1.x 版不兼容或至少有很大不同），而 MINOR 是您的错误修复版本或次要增强. 只要遵循 XY 格式，还可以使用其他系统，如 YEAR.MONTH (2009.12) 或 YEAR.RELEASE (2009.3)。但实际上，除非您有充分的理由不这样做，否则您可能最好坚持使用 MAJOR.MINOR。
绝对不要使用任何不适合 XY 格式的东西，因为它会让发行版、公告网站等难以与您合作，仅此一项就会严重影响您项目的受欢迎程度。
在您的（最好是分布式的）版本控制系统中使用分支和标签将特定的内部版本号分别标记为与 MAJORS 和 MINORS 相关。
是的，1.0 应该是稳定的。所有版本都应该是稳定的，除非它们被标记为 alpha、beta 或 RC。将 Alphas 用于已知的损坏和不完整。已知损坏的 Betas。RC 表示“试试看；你可能会发现我们错过的东西”。任何没有其中之一的东西都应该（当然，理想情况下）经过测试，已知良好，拥有最新的手册等。
于 2009-03-05T15:44:04.780 回答
3
版本方案：[major].[minor].[devrel][mark]
[major]：如果您在开发中有重大变化，则增加。
[minor]：如果您在开发中有微小的变化，则增加。
[devrel]：如果您有错误修复，则增加。如果major++ 或minor++ 则重置为零。
[标记]：a、b 或 rc：a 是 alpha 版本，b 是 beta 版本，rc 是候选版本。请注意，1.3.57a 或 1.3.57b 或 1.3.57rc 等版本在 1.3.57 之前。从 0.0.0 开始。
于 2013-07-04T21:55:00.290 回答
2
如果它在 SVN 中，那么为什么不使用 SVN 修订号？
如果您查看此网页的右下角，您将看到 Stack Overflow 版本号，即 SVN 修订号。
于 2009-03-05T15:23:11.557 回答
2
现在很流行只使用 Subversion 修订号。
于 2009-03-05T15:23:22.100 回答
2
版本控制取决于您；我会将 1.0 放在我有信心的第一个版本上。您可能希望快速跟进其他版本，因为一些软件供应商给 1.0 带来了坏名声。
您确实希望通过某种方式将版本号与所使用的确切构建联系起来，但您可能希望它对您的最终用户来说既好又简单。考虑使用标准版本号，并使用包含的版本号标记 SVN 存储库。
于 2009-03-05T15:26:19.927 回答
2
虽然只使用 Subversion 修订号既好又简单，但它确实从版本号中删除了信息。用户可能会认为这是一件坏事。
我假设您的 webapp 将有某种部署过程，因此并非 Subversion 中的每个修订版都实际发布。由于不可能从“外部”（从用户的角度）确定何时发布，以及代码将在它们之间进行多少次修订，这使得数字几乎是随机的。它们会增加，我想从比较两个修订版可以推测出某种距离，但不会太多。
经典版本号倾向于“戏剧化”发布，以便用户可以建立某种期望。认为“我有 1.0 版，现在 1.1 版添加了这个那个，这听起来很有趣”比认为“昨天我们运行 SO 修订版 2587，今天是 3233，它一定要好得多！”更容易。
当然，这种戏剧化也可能被夸大，公司选择的版本号听起来比产品的实际差异更有趣，我想用修订号来反驳这一点。
于 2009-03-05T15:28:08.597 回答
1
我们花了太多时间来决定何时增加主要版本。有些商店很少这样做，因此您会发布 1.25.3 之类的版本，而其他商店会一直这样做，为您提供 15.0
我受够了这一点，并说服大家主要版本号只是一年，而次要版本只是一年内的连续版本。用户似乎很喜欢它，并且想出下一个版本号是不费吹灰之力的。
Year.Release.build
- 年份 = 当前年份
- 发布 = 具有新功能的公开发布的序列号 - 每年重置为 1
- build = 针对错误修复和内部发布而增加
编辑
** 现在这是针对不断增强的内部应用程序 **
这可能不适用于商业应用程序，因为在一年中的不同时间发布主要版本以用于营销和财务目的很重要。
于 2009-03-05T16:48:07.343 回答
1
存在这个问题的原因是因为我们没有一个统一的方式来进行配置管理。
我喜欢做版本号的方式只是从 1 递增整数。我不想要一个我必须解释或记录的多部分版本号。而且我不想使用 SVN rev number，因为这也需要一些解释。
您需要在 SVN 之上的一些发布脚本来实现这一点
于 2009-03-06T17:44:58.477 回答
0
我在该地区的经验很少。但是，这就是我要做的：
- 选择一个编号修订方案并坚持下去。始终如一。
- 每个版本的变化都应该代表一个重大的变化。更改的重要性以及版本号中反映的更改级别取决于您。
当然，您可以只使用 svn 修订号 --- 就像许多其他人建议的那样！！！
我希望这有帮助。
于 2009-03-05T15:30:29.493 回答
0
我们使用简单的major.minor.julian_date 语法。
在哪里;
- 主要 - 第一个版本是 1，然后当我们引入主要的新功能或更改非常重要时，它们不向后兼容会增加这个数字。
- 次要 - 主要里程碑版本。对于生产推动的每个构建，这个数字都会增加。
- julian_date -构建被推送到 QA的Julian Day 。
1/15 推送到 QA 的第
一个版本的示例是 -> 1.0.015 3/4 推送到生产的第一个版本的示例是 -> 1.1.063
它并不完美，但很方便，因为我们几乎每天都会将构建推送到 QA。
于 2009-03-10T03:28:18.067 回答
0
这里有一些很好的信息：
首先，文件版本和程序集版本不必相互一致。我建议文件版本随着每次构建而改变。但是，不要在每次构建时更改程序集版本，以便您可以分辨同一文件的两个版本之间的区别；为此使用文件版本。决定何时更改程序集版本需要对要考虑的构建类型进行一些讨论：运输和非运输。
非发货版本 一般来说，我建议在发货版本之间保持非发货组件版本相同。这避免了由于版本不匹配而导致的强命名程序集加载问题。有些人更喜欢使用发布者策略为每个构建重定向新的程序集版本。但是，我建议不要将其用于非运输版本：它并不能避免所有加载问题。例如，如果合作伙伴 x 复制您的应用，他们可能不知道安装发布者政策。然后，您的应用程序将被他们破坏，即使它在您的机器上运行良好。
但是，如果同一台机器上的不同应用程序需要绑定到程序集的不同版本，我建议为这些构建提供不同的程序集版本，以便可以为每个应用程序使用正确的程序集版本，而无需使用 LoadFrom/etc。
发布版本 至于为发布版本更改该版本是否是一个好主意，这取决于您希望绑定如何为最终用户工作。您希望这些构建是并排的还是就地的？两个版本之间有很多变化吗？他们会破坏一些客户吗？您是否关心它会破坏它们（或者您是否想强制用户使用您的重要更新）？如果是，您应该考虑增加程序集版本。但是，再一次，请考虑这样做太多次可能会在用户的磁盘上乱扔过时的程序集。
当您更改您的程序集版本时要将硬编码版本更改为新版本，我建议在头文件中为版本设置一个变量，并将源代码中的硬编码替换为该变量。然后，在构建期间运行预处理器以放入正确的版本。我建议在发货后立即更改版本，而不是之前，以便有更多时间来发现由于更改而导致的错误。
于 2009-04-13T20:52:18.897 回答
-3
或使用您的“想法”版本号逗号颠覆号.. zB：
1.0.101 // 修订版 101，发布
或 1.0.101-090303 // 有发布日期，我用这个
于 2009-03-05T15:24:49.070 回答