【问题标题】:How to define the version number of a software?如何定义软件的版本号?
【发布时间】:2010-11-11 21:27:19
【问题描述】:

确定我应该为软件或组件使用的版本号的最佳方法是什么?是否有设置版本号的一般规则?

我很确定这是一个基本问题,但搜索了一段时间后我没有发现任何有用的东西。

【问题讨论】:

    标签: language-agnostic versioning


    【解决方案1】:

    微软有一个约定:

    [major].[minor].[revision].[build]
    

    或关注Jeff's versioning system

    【讨论】:

    • 修订版和构建版有什么区别?
    • @victor:通常不同之处在于每次发布到野外时,修订版本都会增加。内部版本号由构建机器分配或基于日期分配。所以在内部你可能有一大堆 1.0.0.something 候选版本。当其中一个最终验证时,您将其作为“发布 1.0.0”发布,但内部版本号仍保留在末尾,以确保您不会将其与任何内部版本混淆。
    【解决方案2】:

    在找到更好的解决方案之前,我一直在做这件事。我不会构建很多大型应用程序,主要是报告和较小的宏,但跟踪更改和版本对我来说仍然很重要。

    [当年].[当月].[当天]

    例如文件名 9.7.17.rpt。

    它适用于我和我的老板,它提供了一个值,您可以将其与今天的日期进行比较,以了解文件的年龄。我还将 changelog.txt 文件保存在与最新版本相同的文件夹中,它会跟踪以前版本的所有更改。我还在 OneNote 中每个项目选项卡上的版本控制页面中跟踪所有版本。

    感谢您的回答。我还将介绍我是如何存储项目的。

    每个项目都有自己的文件夹。在该文件夹中,我将有 4 个主要项目来帮助我跟踪项目中发生的事情。

    • 旧版本文件夹
    • 一个文件夹,用于存放我项目可能需要的任何参考资料
    • 实际项目文件
    • 还有变更日志

    那棵树看起来像这样。

    Project X
        Old versions
            X Report 9.4.12.rpt
            X Report 9.5.3.rpt
            X Report 9.7.20.rpt
        Reference
            SQL calls.txt
            Client list.txt
            Procedures.doc
        X Report 9.7.29.rpt
        X Report changelog.txt
    

    这种跟踪我的工作的方式确实减少了我需要花在记录任何东西上的时间,并以标准的方式组织它,所以如果我的老板需要抓住我工作过的东西,即使他知道究竟是什么意思以及它在哪里。

    为了在我的网络文件夹中存储多个项目,我有这些文件夹。

    • 收件箱
    • 项目
      • @Archived 项目
      • 当前项目 1
      • 当前项目 2
      • 当前项目 3
    • 参考

    收件箱是我将随机的东西扔到以后处理的地方,或者是我的老板可以扔掉我以后项目需要的东西的文件夹。 Projects 文件夹包含我当前正在处理的所有项目,然后当我完成或它们不再成为当前优先级时,它们会被扔进@Archived Projects。 Reference 是一个存放一般工作参考资料的文件夹,例如政策和程序、电话清单、组织结构图、火灾逃生计划。我可能永远不会使用它们,但有一个地方可以放置这类东西而不是翻阅旧电子邮件,这很令人欣慰。

    【讨论】:

    • 我会得到一个不那么模糊的时间戳,比如 20090729 而不是 9.7.29
    【解决方案3】:

    就像 Donald Knuth 对 TeX 所做的那样——它的版本在每次发布时都会收敛到 π,并且实际上会在他死后变成 π。

    从版本 3 开始,TeX 使用了 特殊版本编号 系统,其中更新已 通过添加一个额外的数字表示 小数点的末尾,所以 版本号渐近 接近 π。这是一个反映 TeX 现在非常稳定的事实, 并且只有较小的更新 预计。当前版本 TeX 为 3.1415926;上次更新 2008 年 3 月。

    来自Wikipedia

    【讨论】:

    • 这很有趣,但是 Knuth 已经做到了,难道还有其他东西会聚集在 e 上吗?所以在它说“特质”的地方,那是“Knuth 可以做他喜欢做的事,这并不意味着你应该模仿他”的代码;-)
    【解决方案4】:

    一个常见的方案似乎是使用 [major].[minor].[revision]。主要版本号在大/主要功能更改或重写时增加(或者只要您没有达到稳定版本就保持 0,尽管许多开源项目在这里从未超过 0),次要版本号在较小更改时增加,例如错误修复的集合,添加的小功能等。每次构建都会增加修订版本,并反映跟踪您的确切版本的最小粒度。通常情况下,诸如小修复之类的东西都会被卷入其中。

    【讨论】:

      【解决方案5】:

      或者,您可以遵循 Ubuntu 使用年份和月份的约定。

      例如,2009 年 4 月的发布将是:

      v9.04
      

      【讨论】:

        【解决方案6】:

        取决于很多事情。

        如果您在做 .Net 工作,您可以让系统自动跟踪您的 .dll 和 .exe 文件的版本号。

        我们经常使用 subversion 修订作为我们版本号的一部分。我们使用这样的系统:

        major.minor.svn 版本

        我们根据内部决策手动增加主要/次要,并传播 svn-version 以区分构建。

        最重要的是版本号对您的用户有意义。

        【讨论】:

          【解决方案7】:

          这是一个很常见的问题。你确定你搜遍了吗?维基百科上有一篇关于software versioning 的好文章。

          【讨论】:

          • 真丢脸我应该发现的。我想是我的英语很差,没有使用版本作为动词
          【解决方案8】:

          通常第一个数字是主要更改/主要版本,第二个数字用于添加次要功能和错误修复,第三个数字用于次要错误修复和修订号。

          例如。 1.0.0

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 2017-11-06
            • 2020-08-31
            • 1970-01-01
            • 2022-01-02
            • 1970-01-01
            • 1970-01-01
            • 2010-11-16
            • 1970-01-01
            相关资源
            最近更新 更多