2008-10-10 87 views
7

我们的情况如下,但在任何情况下我都很好奇这个问题。你如何版本你的项目和管理版本?

我们拥有包括4个项目的框架:

  • UTIL
  • 框架
  • 网络

我们还需要一个版本,并依赖于一个模块bean和util版本。

最后,我们有一个客户项目,其中包含特定版本的核心项目和一个或多个模块。

是否有标准的方式来版本这些项目?

当我们尝试向QA发布发布,然后通过维护版本(发布=标签和可能的分支)来管理我们正在进行的开发时,对我来说看起来很简单的事情变得非常复杂。

我更喜欢以下内容:

1.2.0 - 主要和次要版本+发布。

1.2.1 - 下一个版本

1.2.0_01 - 在1.2.0版本(分支)的bug修复

任何想法?

回答

10

我们使用major.minor.bugfix。主要版本只发生巨大变化。 API发生更改时会调用次要版本。所有其他版本都是bugfix版本。在编译或修订编号方面也有明确的实用工具,可以用于故障排除,但如果您有非常严格的CM,则可能不需要包含它。

在Apache Ivy或Maven等工具的帮助下,可以很好地协调所有这些项目的版本。使用自己的版本号构建一个项目可以涉及其他项目(的产品)的特定版本的汇总,因此您的构建文件从下到上提供了严格的版本映射。将其全部保存到[在此处插入最喜欢的版本控制工具],并记录下不错的历史记录。

+0

我曾经工作过的一个地方做过major-minor-bugfix,真的很认真,只是为了增加巨大的东西而增加了专业。他们已经存在了15年,我正在研究最新最好的版本:1.52.0 :) – tloach 2008-10-10 17:54:16

2

没有标准的版本号系统。共同的主题是有一个主要的,次要的和内部编号,偶尔还有一个点编号(1.2.2.1,例如,对于1.2版本的第2版第1版)。版本号的含义非常灵活。然而,频繁的选择是在小版本或点发布之间具有向后兼容性。

只要您的源代码管理允许,发布可能最好通过标记一组源代码控制文件来完成。然后重新创建一个版本,就像同步到标签和建筑物一样简单,这非常有用:)

2

在自动构建系统中,我目前使用I版本与Major.Minor.Build.X,其中构建是每我们打了系统测试的时间,X是从代码生成的repo中获得的最后一个Subversion修订版本号。似乎Subversion能够很好地工作,因为如果需要的话,我们可以轻松地回到特定构建的代码库。

1

在可能的情况下,我更喜欢使用相同版本编号版本的项目,除非它们是共享的。它允许移动部件之间更加一致,并且更容易识别构成产品发布的组件。

正如workmad3所说,构建数字确实没有共同的规则。我的建议是使用对你的团队/公司有意义的事情。

我曾经工作过的一些地方已将项目里程碑和迭代的内部版本号对齐,
e。g:Major = Release或Milestone,Minor =迭代,Build =内部版本号(从项目开始或迭代开始),Revision =如果构建必须重建(或分支)。

3

我使用{major}。{minor}。{buildday}。{sequential}。对于Windows,我们使用实用程序stampver.exeUpdateVersion.exe来处理主要自动处理的.NET项目。

0

您没有提及任何项目是否访问数据库,但是如果有的话,这可能是另一个需要考虑的因素。我们使用一个major.minor.bugfix.buildnumber方案,类似于在这个问题的答案中描述的其他方法,具有大致相同的逻辑,但是要求任何数据库模式更改至少需要一个小增量。这也为您的数据库模式提供了一个命名方案。例如,版本1.2.3和1.2.4都可以针对“1.2”数据库模式运行,但版本1.3.0需要“1.3”数据库模式。

+0

我们正在使用autopatch。它会自动保持数据库在部署新版本时保持最新。 (跟踪他们在补丁表中)这很不错。 – ScArcher2 2008-11-06 16:40:56

-1

目前我们还没有真正的版本控制。我们使用svn内部版本号和发布日期。 (标记名称是像release_081010_microsoft例如)

老产品使用major.minor.sub版本编号

主要从未改变 的微小变化对每一个版本/每6个月featurerelease。 Sub是不影响功能集的一切 - 主要是bug修复。

2

我用的是Linux内核的版本编号系统的变化:

major.minor.bugfix

,甚至微小的数字表示几分稳定版本可至少被分配用于测试,和奇怪的次要数字表示一个不稳定/未经测试的版本,不应该分发给开发者。

1

其中最常见的约定是major.minor.bugfix,并带有一个表示内部版本号或预发布标识(例如alpha,beta等)的附加后缀。

我的团队编号根据项目里程碑进行构建 - 在开发迭代结束时(每隔几周)将构建交付给我们的QA组。临时CI构建未编号;因为我们使用Maven,所以这些版本会以SNAPSHOT后缀编号。

无论你决定什么,一定要记录它,并确保每个人都明白它。我还建议您记录并始终应用发布分支政策,否则它可能会很快让每个人感到困惑。虽然只有4个项目,但应该很容易跟踪发生的情况。

+0

太棒了,我们也使用maven。这听起来像我们的计划与你所说的相似。我完全同意让其他人了解这个过程是关键。 – ScArcher2 2008-10-16 14:48:41

相关问题