Rubyist

如何优雅的升级Ruby项目

一个长期维护的项目不断轻松稳定的升级也是一件很有挑战的事。很多项目因为没有及时升级导致升级越来越困难,维护成本越来越高。自从Bundler的出现,Ruby项目的依赖管理变得方便和稳定。

但是从最近的一个帖子(http://ruby-china.org/topics/172)发现,在处理gem升级的问题上还存在一些分歧,升级方式主要有三种:

  1. optimistic[乐观]
  2. pessimistic[悲观]
  3. super pessimistic[超级悲观]

以nokogiri这个gem为例:

gem nokogiri #optimistic
gem nokogiri, >=1.4.2 #optimistic
gem nokogiri, ~>1.4.2 #pessimistic
gem nokogiri, ~>1.4 #pessimistic
gem nokogiri, 1.4.2 # super pessimistic

第一种方式很少人采用,因为一旦升级很容易因为API不兼容导致你的项目爆掉。

主要分歧在第二种和第三种。选择第三种方案(super pessimistic)的观点通常是锁定版本号稳定,升级会带来麻烦,以前升级出现过问题,求稳等各种原因。

我比较推荐第二种(pessimistic)升级方式。

先解释下>=1.4.2、~>1.4.2、1.4.2之间的区别:

gem nokogiri #任何版本
gem nokogiri, >=1.4.2 #任何大于等于1.4.2的版本
gem nokogiri, ~>1.4.2 #大于等于1.4.2并且小于1.5.0版本
gem nokogiri, ~>1.4 #大于等于1.4.0并且小于2.0.0版本
gem nokogiri, 1.4.2 # 只能等于1.4.2

还要说明一下Ruby gem采用的 Semantic Versioning

还拿nokogiri 1.4.2为例:

  • 1 → Major版本,在接口重构情况下Major Version会增加,API不一定向后兼容
  • 4 → Minor版本,在增加新特性情况下Minor Version会增加,并且 API保持向后兼容
  • 2 → Patch版本,在bug fix的情况下Patch Version会增加,并且API保持向后兼容

可见,使用第二种方式既不会出现API不兼容问题,又会及时升级到没有bug的版本。与第三种比较,优点是: 升级方便,不需要修改Gemfile,直接运行bundle update,所有的gem升级到最新,如果需要升级gem的主版本号才需要更改Gemfile.

而指定版本号的方式需要知道最新版本是多少,并且一个一个的改版本号。增加了升级的复杂度。而实际上锁定版本号的项目几乎没人去升级…

Bundler的FAQ也提到锁定版本号的缺点:FAQ: Why Can’t I Just Specify Only = Dependencies?

FAQ:

问:gem作者不遵守semver规则怎么办?

答:放弃使用他的gem!这也应该成为选择gem的衡量标准之一。曾经rubygems自己没有遵守这个规则,1.8.x系列修改了Public API导致大量gem安装出现问题。 Loren Segal 从rubygems fork出了SlimGems,并且承诺长期维护和1.3.7兼容的API。

问:如果升级Patch版本号真的出现问题了怎么办?

答:哪个gem出问题了找到问题的原因解决问题,如果解决不了可以不升级那个gem

相关资源:

标签 Bundler, SlimGems, Patch, Major, Minor, update, Semantic Versioning

Avatar
hiveer 大约 5 年 前

第二种方法也不是万能的,就像我们需要一个gem的新特性的时候,Major版本不一致,向后不兼容就是要面对的一个问题。

(使用BBCodeTextileGist)