我注意到通过 GitHub 发布的 GEM 的质量与 RubyForge 的 GEMS 的整体质量相比有所下降。
恕我直言,这种行为至少有两个主要解释:
--
在 GitHub 之前,99% 的 Rubyist 都依赖于 Subversion。你可以说出你对 Subversion 的看法,但与 Git 相比,它肯定更容易使用,而且每个人都知道 trunk/tags/branches 布局。然后人们开始转向 Git。只有极少数的 Subversion 用户开始使用 Git,并且具备所需的知识水平,而我注意到,人们开始忘记标签。
从前有标签。在颠覆中,人们习惯于根据特定标签发布新版本,以便您可以轻松检测您安装的版本以及哪个是稳定分支。
现在我看到大量的库总是在 Git master 分支中开发。没有标签,没有稳定的分支。通常,当通过 RubyForge 发布库时,对部署步骤的关注程度更高。
--
GitHub 让发布步骤不再麻烦。也就是说,您可以轻松地发布一个新的 GEM,只需将 gemspec 推送到您的存储库中。
在我看来,这种简单性可能会导致质量下降。更多不熟练的开发人员开始分发 GEMS,因为它就像使用 Jeweler(或类似的库)生成新项目并推送 git 存储库一样简单。他们对发布管理、向后兼容性、发布冲突、发布维护了解不多。
我经常遇到打包为 GEM 的未完成库,只是因为开发人员忘记远程 .gemspec 文件。每次提交都会导致构建一个新的 GEM,但没有明显的连贯性和一致性。
我绝对赞成“经常发布”的做法,但当它有意义时。Git 提供了出色的分支支持,您无需将大量不相关的提交弄乱主分支并释放您称为库的未完成代码。
--
最后但并非最不重要的一点,我最讨厌的可能是同一个 GEM 的无限复制。当 RubyForge 是无可争议的 GEM 源时,很容易找到并安装一个新项目。
恕我直言,GitHub 引入了不必要的复杂层。首先,您可以通过 rubyforge asmygem
和 GitHub as获得 GEM username-mygem
。您经常需要花时间弄清楚哪个 GEM 是最新的并掌握了主开发。
此外,一些流行的 GEM 不再在 RubyForge 上更新,许多人继续使用它们只是因为 RubyGems 没有通知您新版本。很容易理解,如果您安装了coolgem
1.2.4 版并且现在可以使用相同的库作为超级用户-coolgem(2.0 版),那么 RubyGems 不够聪明,无法告诉您有新的更新可用。
--
现在是免责声明的时候了。
与 RubyForge 相比,我并不是说 GitHub 用户生产的 GEMS 很糟糕。我是 GitHub 用户,之前我也是 RubyForge 用户。数以千计的 GEMS 成功地从 RubyForge 迁移到 GitHub,而没有让最终用户陷入“哪一个”的困境。
最好的例子 Rails,但我可以提到许多其他 GEM,包括(但不限于)Capistrano、Hpricot、RedCloth...所有这些库现在都托管在 GitHub 上,如果您仔细查看它们,您可以轻松识别出相同级别的质量一如既往。
最后但同样重要的是,所有这些库继续通过 RubyForge 作为主源发布,因此您无需重新配置环境来检测是否安装 rails-rails 或 rails。
此外,最终用户不受开发决策的影响。以 Capistrano 为例。几个月前,Jamis 宣布终止对开发的承诺。社区负责开发并将主存储库从 jamis/capistrano 移动到 capistrano/capistrano。如果 GEM 以 jamis-capistrano 的形式发布会怎样?所有用户都必须切换到新的 GEM 和新的存储库,非常麻烦。
这种情况从未出现过,因为 RubyForge 曾经并将继续是 Capistrano 的主要交付中心。
--
总之,我很遗憾地注意到 GEM 质量的总体下降主要是由于更多人在没有必要知识水平的情况下使用 Ruby 和 RubyGems。这同样适用于大量 Rails 插件。
GitHub 不能被标记为罪魁祸首。当复杂的事情变得更容易并且更多的人在没有基础知识的情况下接近它们时,质量会降低是正常的,因为复杂性是自然选择的过程。
无论如何,Ruby 社区的质量仍然很高。看到 Ruby 开发人员如何致力于单元测试和其他专业的编程习惯,真是令人惊讶。