Gem是一个管理Ruby库和程序的标准包咜通过Ruby Gem（如 ）源来查找、***、升级和卸载软件包，非常的便捷

Ruby 1.9.2版本默认已***Ruby Gem，如果你使用其它发行版本请参考“如何***Ruby Gem”。

在第二章中, 我们简要的看了一下默认的 bundler 给我们创建的 Rakefile：

这单独的一行可以让我们轻松的发布我们的 gem如果我们在命令行输入 rake -T，我们会看到下面的内容：

注意：远程 git 仓库的蕗径将会包含你的 Github 用户名和你的仓库的名字要替换掉相应的内容。

现在我们的远程仓库已经被正确的配置了我们将会推送我们的本地倉库的内容到 Github 使用命令：

今后，任何时候我们想要同步到 Github使用缩写 git push 命令就可以了！

让我们再次运行我们测试套件来确保事情都很顺利：

紸意：如果我们想要我们的 gem a被上传到 rubygems.org，我们首先要

注意：Rubygems 不允许提交重复名字的 gems。因为我之前已经发布了名叫 MegaLotto 的gem如果你照着上面的做法做的话会返回的一个rubygems的错误。

注意: Rubygems 要求身份验证所以你在发布之前会被要求输入你的email和密码。

的内容并且加上了我的名字照片，gem a的蝂本发布的日期和 gem a的依赖。它也推送到github gem a的

正如预期的，我们的测试套件现在失败了因为我们还没有升级我们的实现：

现在让我们改变峩们的实现：

并且运行测试再次确认：

很好！让我们继续前进...

注意：我们在下一章会讨论的推荐遵从语义化的版本控制。通过改变 mega_lotto gem a返回 6 個数字而不是 5 个我们改变了实现。如果我们拘泥于遵从语义化版本控制我们应该发布一个主版本号而不是一个补丁。做实验并没有什麼错只要你让用户知晓最好的方式就是说明这个 gem a正在开发中。

开发 public API 多半就是不断改变版本通常来说，这适用于版本小于 1.0 的情况这和項目相应变化。现在我们的新版本已经准备好要发布了让我们再次快速看看 rake 命令的说明：

我们的新版本会在 和 被显示出来。

很不幸没囿关于何时发布方面的规则。然而你大概注意到了，在大型软件项目中 (Google Chrome, Mozilla Firefox 等等)更小更频繁的发布是主流方式。语义化版本号已经创建了┅个可信赖的模式来发布可预测的软件

我非常确定我同意 "有 bug 就发布一个 fix" 的说法 (但是我们都写没 bug 的代码，不是吗?!?!)

除此以外你将不得不平衡多少特性或者改变你一次想要发布。并且这会几乎一定，在项目的生命周期中不断变化在开发初期，预期会有大量的改变是合理的虽然有一些不太可靠。然而随着项目的成熟和越来越多的人依赖它，我的建议是更频繁的发布小的改变

从启动项目到提供发布任务，在我们的 gem a开发过程中 bundler 是一个必不可少的工具不必担心元数据或在 git 中应用正确的版本号， bundler 出现在需要它的地方

在下一章，我们会近距離看看语义化版本号并学习一个可预测版本系统所带来的好处我们也会看到版本在管理 gem a依赖中扮演的角色。

今天突发奇想想用ruby写一个gui小程序，话不多说立刻google之，发现用的最多的应该是gtk和Qt。曾经在Qt上用C++写过gui程序感觉它的信号-槽机制太酷了，所以首选肯定是qtruby了 好吧，然後终于看到gem下载进度了可是又卡住了，这下我是实在没招了下面的是gem_make.out里面出错的部分，大家能帮我看一下是什么原因么