1

我正在尝试采用命名版本的良好做法。

我已经完成了我的项目的编码。由于它可能包含未知错误,我将其标记为“v1.0rc1”。找到并修复所有错误后,我会将更新的版本标记为“v1.0”。

但是,如果没有发现任何错误,并且候选版本证明对于最终版本来说足够好怎么办?

使用 SCM,就像用“v1.0”标记最后一次提交一样简单。

问题在于更新发行版。我使用 RubyGems。它的约定是将版本号存储在代码中。在构建 gem(发行版)时,RubyGem 将版本号放入 gem 的文件名中并将其上传到存储库中。

如果我更改版本号并更新 gem,所有用户将被迫下载整个发行版而没有任何好处。我认为这是一种糟糕的做法。

另一方面,我既不想永远留在“v1.0rc1”,也不想发布可能包含错误的最终版本。

有没有一种方法可以让您同时发布候选版本并且不强迫用户重新下载无用的版本?

4

2 回答 2

1

这里的问题是代码更改没有正确传播给构建的使用者。由于消费者无法分辨哪些发生了变化,哪些没有发生变化以及这些变化的影响可能是什么,他们不得不重新下载所有内容。

您可以做的是将您的产品分成许多小部分,这样下载量就会很小。但这是一项巨大的维护工作,以今天的下载速度可以为人们节省几秒钟的时间(您的产品不是 400MB,是吗?)。

我希望我们最终能够创建使用散列和时间戳来确定是否发生变化的构建系统。该信息可以包含在下载中,或者提供下载和依赖管理系统的服务器可以

  1. 仅下载更改的部分(即包含新版本号的单个文件或仅下载所述文件中单个常量的新值)
  2. 并确定您的代码更改是否会影响我的代码,如果是,哪些部分。
于 2013-04-10T11:52:15.987 回答
1

不要为此出汗,因为:

  1. 有些产品永远不会“退出测试版”或使用 rc 方案,因此它们完全避免了这个问题。

  2. 除非他们特别要求,否则大多数用户不会下载 rc 版本,因此大多数用户不会受到影响,除非您不得不拉出当前版本并在不久之后发布另一个版本,现在这真的会给人们带来不便。(我可以回忆起不止一把这样做的宝石,但我离题了)

  3. 总会有错误。

于 2013-04-10T12:16:23.747 回答