我们目前有许多办公产品和嵌入式产品。它们都具有相同的版本方案 major 。 minor 。内部版本号。 svn revision 。使用夜间和手动构建增加内部版本号。
从开发支持方面来看，这使得管理“正确版本”变得非常容易，但是当一个工具从v10变为v200并且我们说没有变化时，现场支持人员会感到恐慌。
由于我们对它的喜爱，这个方案（全部同步）是否有任何问题？
更新： 这是内部版本号正在飞跃增长，主要次要内容只会按年度类型进行更改。
svn revision 对于x时刻的所有文件都是一样的，但是没有人真正注意到这一点。
所有.exe和.dll等都有相同的X.Y.W.Z编号。因此，当我们对嵌入式产品进行大量工作时，办公产品将从1.1.10.1234升至1.1.132.4321。
答案 0 :(得分：1)
我不会说这是一个问题，只要他们可以轻松查找更改日志以查看更改内容。
从逻辑上考虑，如果任何产品中没有更新库，也没有对产品本身进行任何更改，则版本号应该保持不变。
我能提出的唯一建议是转移到过时的版本号，这样主要版本和次要版本的变化不会那么快。像9.0417.yyyy.xxxx这样的东西将是2009年4月17日的版本，其中yyyy和xxxx的内部版本号为svn版本。如果您不想更改主要编号并希望将日期保留在次要编号中，则可以使用Microsoft的版本控制样式。有一篇关于微软如何在http://blogs.msdn.com/jensenh/archive/2005/11/11/491779.aspx进行版本控制的博客文章。
答案 1 :(得分：0)
我使用了聚合版本控制方案。所以你说你有很多产品，如果部署的字段版本各自共享相同的版本号 - 我假设这意味着如果你更新你的嵌入式库，办公产品不使用这些库，办公产品仍然得到一个新版本号，即使代码中没有更改。
因此在聚合方案中，SYSTEM有一个大的版本号，每个子系统都有自己的版本号。我使用的是clearcase表示法，因为我不知道svn中equivelant的术语：顶级组件在其下面有一个子组件（想象一个组件就像一个包含代码的文件夹，这样所有的东西都在该文件夹共享相同的版本，或“基线”，如clearcase所称。）
如果我在顶级系统组件中创建新基线（版本），它会使用新版本标记它，并且所有子组件也会获得新版本（可能使用不同的版本控制方案），但仅限于它们'我改变了。
我们为顶级系统版本使用日期时间基准和“版本号”。然后，每个子系统都包含major / minor / build / svn。另外，我们不会在“about-＆gt; help”或equivelant中显示svn和内部版本号，只有当你深入到某个“系统配置”文件中时才能提取实际的build / svn数字（例如，通过查看可执行文件中的元数据）。这样，用户只看到主要/次要版本，而不是构建和svn数字的gobbledigook。