瞎扯淡 者也的代码还维护吗
前几天打算学习下 mongodb，把者也的代码 clone 下来，发现者也的 Gemfile：
gem "mongoid", "2.0.0"
gem "bson", "1.2.4"
gem "bson_ext", "1.2.4"
gem 'mongo-rails-instrumentation', "0.2.0"
gem "mongoid-eager-loading","0.3.1"
gem "mongoid_rails_migrations", "0.0.10"
gem "cells","3.6.5"
gem "dalli","1.1.2"
gem "redis", "2.1.1"
# Vote 插件 for Mongoid
gem 'voteable_mongoid', "0.6.0"
# 分词
gem 'chinese_pinyin', '0.3.0'
gem 'rmmseg-cpp-huacnlee', '0.2.9'
# 用户系统
gem 'devise', '1.2.rc2'
# 邀请系统
gem 'devise_invitable', '0.4.rc5'
几乎所有 gem 都固定到某个版本上了，有些还是 rc 版本。 我试着把 mongoid 升级到最新，可是我发现已经很困难了。其他依赖 mongoid 的插件也必须升级，有些已经没人维护了... 最后就这样放弃了。
我已经很久没维护过了，现在已经放弃那个项目~ Gemfile 我是特意锁定的，升级某些新版本会带来很多问题，尤其是和数据有关的，之前有过前车之鉴，于是后面所有项目的 Gemfile 里面都把 gem 的版本固定了。
者也已经完成历史使命了.. 狠狠嘲讽了一下知呼 #10 楼 @sihaiyunyou 也别那么苛刻了，毕竟工作也很忙的，同时维护好几个开源项目一点不轻松的
@hooopo 当然会升级，一般会是大的 Rails 升级，然后 gem 跟着升级，不会每一个 gem 有更新了，你就跟着更新的 , 要是这样做的话，我也就对他无语了 ...
@wxuabfebg 我上面已经说了用 gem 'devise', "~>1.2.x"这种方式。而不是直接锁定版本号。正如你说的不会每一个 gem 有更新了就去升级。但是却可以一行命令：
bundle update
来把所有的 bug fix 版本升级到最新。不需要你去改 Gemfile 特别是 rc 版本更不应该锁定
作开发的人求追新，作产品的人求稳定，呵呵。 以前公司同事在头脑风暴的时候，抛出一个想法，把项目中的 rails 版本跟 github 上的 master 同步，这么作的好处是永远不会出现大版本升级过程中带来的痛苦，而且还随时可以享受新功能带来的便利，如果遇到 bug，还能跟 Rails 团队一起抓虫。
后来讨论下来的结果是，我们的产品要对用户负责，所有的技术决策应该由需求和利益推动，而不是去追新，gem 升级如果能够解决问题，带来便利，降低开发成本，或者从长远眼光看能够获益的时候，我们就毫不犹豫升级，反正则需慎重。
@lgn21st 貌似大家没有理解我的意思... 其实我的做法已经是很保守的升级方案了
Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.
自动升级 bug fix 版本是百利而无一害的.. http://semver.org/ @wxianfeng 服务和本地 gem 是否一样和 cache 到 vendor 下与否一点关系也没有 真正有关系的是 Gemfile.lock 这个文件 Gemfile.lock 是维护开发机和服务器第三方库一致的保证 至于你说出现问题可能是你的 bundle 的使用方法错误
@hooopo 指定版本后，Gemfile.lock 当然同步了，cache 到 vendor 下 ,在服务器上 bundle install 失败后，我会从 cache 里装，从 rubygems.org bundle install 经常抽风 , 知道吧!!!
我的意思是不指定版本也同步（当然如果你的 Gemfile.lock 如果没有 check 到版本库，那是你 bundle 使用的问题..） cache 到 vendor 与否是另外一个话题了
@huacnlee 如果 patch 版本不能保证 API 兼容的话还是不要用他的 gem 了... 我找了几个实际的项目，看看他们的 Gemfile： https://github.com/intridea/omniauth/blob/master/omniauth.gemspec https://github.com/plataformatec/devise/blob/master/Gemfile https://github.com/rails/rails/blob/master/Gemfile
Bundler 的 FAQ：http://gembundler.com/rationale.html
FAQ: Why Can't I Just Specify Only = Dependencies?
Q: I understand the value of locking my gems down to specific versions, but why can't I just specify = versions for all my dependencies in the Gemfile and forget about the Gemfile.lock?
A: Many of your gems will have their own dependencies, and they are unlikely to specify = dependencies. Moreover, it is probably unwise for gems to lock down all of *their* dependencies so strictly. The Gemfile.lock allows you to specify the versions of the dependencies that your application needs in the Gemfile, while remembering all of the exact versions of third-party code that your application used when it last worked correctly.
By specifying looser dependencies in your Gemfile (such as nokogiri ~> 1.4.2), you gain the ability to run bundle update nokogiri, and let bundler handle updating **only** nokogiri and its dependencies to the latest version that still satisfied the ~> 1.4.2 version requirement. This also allows you to say "I want to use the current version of nokogiri" (gem "nokogiri" in your Gemfile) without having to look up the exact version number, while still getting the benefits of ensuring that your application always runs with exactly the same versions of all third-party code.
