5

我一直在为版本控制软件苦苦挣扎。我不是在谈论命名约定,而是在谈论如何在构建系统中实际应用一个版本,直到发布。

我一般使用major.minor.maintenance-[release type] ie 1.0.2-rc1

问题是管理版本号。我尝试了很多方法(将其粘贴在构建文件、属性文件、数据库等中),但我没有找到任何真正有效的方法。

我想出的最接近的方法是使用我在此处记录的 Jira:http: //blog.sysbliss.com/uncategorized/release-management-with-atlassian-bamboo-and-jira.html

我想知道是否有人对此有任何好主意。另外,想知道人们如何处理发布版本....即,如果我发布/部署版本 1.0.0-rc1 在此版本中发现错误然后登录到 1.0.0(下一个/生产版本)。

4

6 回答 6

4

Microsoft 使用<major>.<minor>.<patch>-<build number>(或变体)。

我喜欢用<major>.<minor>.<buildnumber>

于 2008-11-04T19:02:31.150 回答
2

现在这可能是一个死帖,但无论如何我都会加两分钱。我认为内部版本号应该对每个看到它的人都有意义。所以我个人认为这是给版本命名的好方法:

major.minor.patch.revision - 例如 1.1.4.2342

主要/次要数字是不言自明的。但从第三个数字的角度来看,它仍然需要对客户有意义。我已经向您发布了这个新版本,客户先生,但它不值得一个新的次要号码,因为我们只是修复了一些错误。所以我们增加了补丁号。

第 4 个数字通常对客户绝对没有任何意义,因此您不妨让它对您和您公司中看到它的任何其他人有用。所以对我们来说,这个数字就是 SVN 版本号。它准确地告诉我们哪个版本负责该版本,以便我们可以随时将其拉出以重新创建它。分支代码显然也实现了这一点,但不是 100% 确定的。

此外,全数字版本号的另一个优点是它可以轻松集成到几乎每个连续构建系统中。

无论如何,这是我的两分钱。

于 2009-03-18T22:26:02.013 回答
2

在我工作的地方,我们使用 Maven 系统:artifact[-major-minor-revision][-SNAPSHOT],它允许我们开发“进行中”的版本,这些版本会立即更改(SNAPSHOT)和那些已经正式发布的版本. 一些例子是:

email-services-1.0.0-SNAPSHOT.jar

  • email-web-2.3.11.war
  • crm-2.5.0.ear
  • 如果它有 SNAPSHOT,那么它还没有通过全套测试,或者只是一个开发者实验。如果它没有 SNAPSHOT,那么它就是一个候选版本。我们维护一个发布候选者的存储库,一旦测试人员对它感到满意,最新的将被发送以进行部署。

    所有这些都可以通过 Maven 下的构建文件中的一些简单条目来管理。见Maven2 教程

    于 2008-11-04T19:40:10.030 回答
    1

    在 Jira/Bamboo 解决方案上 +1。关于构建的唯一附加信息(出于我的目的)是 Subversion 版本,尽管标记操作是我想要的 80%。

    手动维护发布/版本信息是一件非常痛苦的事情。让 JIRA 驱动它是一个好主意。

    关于最后一个问题,关于记录错误/缺陷releasing的位置和版本:

    • 缺陷/问题会针对其出现的版本进行记录。针对 1.0.0-rc1 记录了 1.0.0-rc1 中的缺陷
    • JIRA 有(或者我们可能添加了)一个“Fix-For”字段,该字段将具有计划发布,在本例中为 1.0.0
    • 如果缺陷/问题足够严重,则可能需要添加另一个“rc”版本。
    • 当没有突出的关键缺陷/问题并且客户(或管理层)同意可以推迟任何剩余问题时发布

    通过 JIRA 进行管理的美妙之处在于,添加版本、生成更改日志等自动化程度相当好。

    于 2008-11-04T22:27:43.170 回答
    0

    我们还在<major>.<minor>.<buildnumber>构建服务器上使用 CruiseControl/(.Net) 并对其进行管理。并使用 Wix 和 CruiseControl Config 管理主要次要编号 - 仍然手动增加这些编号 - 但构建号在构建服务器上时会自动发生。我相信您也可以设置一个规则来自动增加主要/次要 - 我们只需要手动执行此操作,以便开发人员在需要命名特定发布级别时进行有意识的思考。

    于 2008-11-04T19:13:33.420 回答
    0

    Major.Minor.BuildDateNumber.DailyBuildNumber

    Major 和 Minor 由我们设置,在我们认为合适的时候手动增加它们。

    BuildDateNumber 是自项目开始以来的月数乘以 100,再加上当月的天数。

    DailyBuildNumber 每天午夜后的每个构建都会递增,从零开始。

    例如,7 月 10 日发布 5.2 的第 4 次构建,该项目于当年 1 月 1 日开始,将具有版本号

    5.2.710.3

    这一切都是由Nant中的 Version 任务为我们计算的。

    这使版本号保持唯一,并且还允许我们快速计算构建安装的时间。

    于 2009-06-11T15:48:43.207 回答