瞎扯淡 者也的代码还维护吗

hooopo · 2011年11月25日 · 最后由 JohnsonWang 回复于 2012年02月04日 · 5455 次阅读

前几天打算学习下 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 的版本固定了。

#1 楼 @huacnlee 为什么放弃了?全新投入 ruby-china?

竟然没有主楼的引用回复。。。。加上这个功能吧。。 @hooopo mongoid 好像有 bug,一年前玩过。。。。

#2 楼 @jinleileiking 搞不起来啊,还不如把精力投到别的地方

锁定比较好,没有特别的原因去升级版本容易出问题。之前我用 paperclip 的时候就因为升级了一个版本号导致无法上传中文名的文件,之后两个版本才改好的。

ruby gem 的依赖关系,如果用自动升级,那就等着悲剧吧。。。

#4 楼 @huacnlee 技术上,web 东西没什么玩意。主要是 idea 和 money。。。。

这么锁定没有好处呀 可以锁定小版本号嘛,使用

gem 'devise', '~>1.2.rc2'

gem 'devise', '~>1.2'

#8 楼 @hooopo 学 mongoid 看毛 zheye 啊,这个论坛不就是 mongo 的么

gem "mongoid", "2.2.4"

#4 楼 @huacnlee 搞不起来说明没有好好搞,做一件事情都是浅尝辄止的话,搞任何事情都搞不起来,你换了方向去搞别的,一样会发现不好搞

者也已经完成历史使命了.. 狠狠嘲讽了一下知呼 #10 楼 @sihaiyunyou 也别那么苛刻了,毕竟工作也很忙的,同时维护好几个开源项目一点不轻松的

#5 楼 @cqpx 锁定有 Gemfile.lock 了 感觉版本用~> 指定比较好

#11 楼 @aNdReW_Qx 我错了,这么说话的确太尖刻,老大也挺不容易的

Gemfile 当然要指定版本了。。。不然随着时间的推移,你就折腾吧 !

#14 楼 @wxianfeng Gemfile.lock 已经锁定了

@wxianfeng 一个正常的项目是应该随着各种插件的升级而升级的,如果没有升级的勇气那么就等着项目以后慢慢烂掉吧

@hooopo 当然会升级,一般会是大的 Rails 升级,然后 gem 跟着升级,不会每一个 gem 有更新了,你就跟着更新的 , 要是这样做的话,我也就对他无语了 ...

@hooopo 当然某个 gem 有 bug 或者有重大问题更新的时候 除外了 !!!

其实如果插件不涉及到数据,很多还是可以升级新版本的

@wxuabfebg 我上面已经说了用 gem 'devise', "~>1.2.x"这种方式。而不是直接锁定版本号。正如你说的不会每一个 gem 有更新了就去升级。但是却可以一行命令:

bundle update

来把所有的 bug fix 版本升级到最新。不需要你去改 Gemfile 特别是 rc 版本更不应该锁定

@hooopo @huacnlee
每个人有自己的方式吧,我手里服务器上维护着几个项目,以前习惯经常升级,一到服务器上 就有问题,以至于导致线上的网站不能访问,来解决问题,后来我就一直 指定版本,并且 cache 到 vendor 下,这样服务器上和本地永远都是一样的,服务器上 bundle install 也会瞬间完成!!! 有维护服务器线上环境的应该遇到过吧!!!

作开发的人求追新,作产品的人求稳定,呵呵。 以前公司同事在头脑风暴的时候,抛出一个想法,把项目中的 rails 版本跟 github 上的 master 同步,这么作的好处是永远不会出现大版本升级过程中带来的痛苦,而且还随时可以享受新功能带来的便利,如果遇到 bug,还能跟 Rails 团队一起抓虫。

后来讨论下来的结果是,我们的产品要对用户负责,所有的技术决策应该由需求和利益推动,而不是去追新,gem 升级如果能够解决问题,带来便利,降低开发成本,或者从长远眼光看能够获益的时候,我们就毫不犹豫升级,反正则需慎重。

@lgn21st 同意 +1 我们长时间总结下来也是这样 稳中求进!!!

@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 与否是另外一个话题了

#20 楼 @hooopo RC 版本有时候也要锁定的,比如 will_paginate 3.0.pre2

#22 楼 @lgn21st 线上产品跟着 Rails master 那不是找死么!Rails release 都还有大问题的

#24 楼 @hooopo 有些 Gem 的 Z 版本不一定靠谱的,所以稳妥的做法还是直接固定一个版本,除非有 Bug,否则尽量不升级版本

#25 楼 @wxianfeng 现在我们的线上服务器都有配置 rubygems.org 的 Hosts

@huacnlee 好,改天我也搞个,国内的网络出口屏蔽实在坑爹!!!

#31 楼 @wxianfeng 很快就会有 Rubygems.org 的国内镜像站了。

@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.

#32 楼 @huacnlee 这个真是非常期待呀

匿名 #35 2011年12月27日

#33 楼 @hooopo 还对者也感兴趣?

#35 楼 @JohnsonWang 那哥们对啥都感兴趣。。。。是吧@hooopo

匿名 #39 2011年12月28日

#38 楼 @hooopo 我给你发一封 email。

匿名 #41 2011年12月28日

#40 楼 @hooopo 嗯?我发到了 [email protected] p 前面 4 个 o 的那个 email 地址了。 就是 github 上的那个 email 地址。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号