如何优雅的升级Ruby项目

为什么80%的码农都做不了架构师？>>>   

作者：hooopo  时间：2011年11月28日 01:14  评论(0)

一个长期维护的项目不断轻松稳定的升级也是一件很有挑战的事。很多项目因为没有及时升级导致升级越来越困难，维护成本越来越高。自从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

转载于:https://my.oschina.net/floger/blog/40412