1

この質問では、rubyforge gem は github フォークよりも公式で、権威があり、安定しているという私の仮定について言及しました。私の質問に答えてくれた人の 1 人は、私の推測は正確ではないかもしれないと言っていました。

何を観察しましたか?人々は github を使って早期にリリースし、頻繁にリリースし、安定したリリースだけを ruby​​forge に置いていますか? それとも、他の理由 (例えば、rubyforge の方が手間がかかる) で ruby​​forge のリリース頻度を減らしているのでしょうか?

更新: この質問は今では少し意味がありません。Github の gem は廃止されrubyforge の gemは ruby​​gems.org に移動されます。

4

4 に答える 4

4

私が気付いたのは、RubyForgeのGEMSの全体的な品質と比較して、GitHubを介してリリースされたGEMの品質が低下していることです。

私見では、この動作には少なくとも2つの主要な説明があります。

-

GitHubの前は、Rubyistの99%がSubversionに依存していました。Subversionについてあなたが望むことを言うことができますが、Gitと比較して間違いなく使いやすく、誰もがトランク/タグ/ブランチのレイアウトを知っています。その後、人々はGitに移行し始めました。Subversionユーザーのごく限られたスライスが、必要なレベルの知識でGitを使い始めました。私が気付いたのは、人々がタグを忘れ始めたことです。

昔々、タグがありました。Subversionでは、特定のタグに基づいて新しいバージョンをリリースするために人々が使用されたため、インストールしたバージョンと安定したブランチを簡単に検出できます。

今日、Gitマスターブランチで常に開発中のライブラリがたくさんあります。タグも安定したブランチもありません。一般に、RubyForgeを介してリリースされたライブラリでは、展開ステップにより高いレベルの注意が払われていました。

-

GitHubを使用すると、公開手順を面倒にする必要がなくなります。そうは言っても、gemspecをリポジトリにプッシュするだけで新しいGEMを簡単に公開できます。

私の意見では、この単純さは品質の低下につながる可能性があります。Jeweler(または同様のライブラリ)を使用して新しいプロジェクトを生成し、gitリポジトリをプッシュするのと同じくらい簡単なため、よりスキルの低い開発者がGEMSの配布を開始しました。彼らは、リリース管理、下位互換性、リリースバンプ、リリースメンテナンスについて詳しく知りませんでした。

開発者が.gemspecファイルをリモートするのを忘れたという理由だけで、GEMとしてパッケージ化された未完成のライブラリに出くわすことがよくありました。コミットするたびに、明らかな一貫性と一貫性のない新しいGEMが構築されました。

私は「頻繁にリリースする」という慣習に絶対に賛成ですが、それが理にかなっている場合です。Gitは優れたブランチサポートを提供します。マスターブランチを大量の無関係なコミットで乱雑にしたり、ライブラリと呼ばれる未完成のコードをリリースしたりする必要はありません。

-

最後になりましたが、私がおそらく最も嫌うのは、同じGEMの無制限の複製です。RubyForgeが挑戦されていないGEMソースであったとき、新しいプロジェクトを見つけてインストールするのは非常に簡単でした。

私見、GitHubは不必要な複雑さの層を導入しました。まず、RubyforgeasmygemとGitHubasの両方でGEMを利用できますusername-mygem。多くの場合、どのGEMが最も更新され、マスター開発を保持しているかを把握するために時間を費やす必要があります。

さらに、一部の人気のあるGEMはRubyForgeで更新されなくなり、RubyGemsが新しいバージョンについて通知しないという理由だけで、多くの人々がそれらを使い続けています。簡単に理解できます。coolgemリリース1.2.4をインストールし、同じライブラリがsuperuser-coolgem(リリース2.0)として利用できるようになった場合、RubyGemsは新しいアップデートが利用可能であることを通知するほど賢くありません。

-

さて、免責事項の時間です。

私は、GitHubユーザーがRubyForgeと比較してくだらないGEMSを生成すると言っているのではありません。私はGitHubユーザーであり、以前はRubyForgeユーザーでもありました。何千ものGEMSが、エンドユーザーを「どちらか」にとどまらせることなく、RubyForgeからGitHubに正常に移行しました。

Railsの最良の例ですが、Capistrano、Hpricot、RedClothを含む(ただしこれらに限定されない)他の多くのGEMについて言及できます...これらのライブラリはすべてGitHubでホストされており、注意深く見ると、同じレベルの以前と同じ品質。

最後になりましたが、これらのライブラリはすべて、マスターソースとしてRubyForgeを介して引き続きリリースされるため、rails(rails)をインストールするかrailsをインストールするかを検出するために環境を再構成する必要はありません。

また、エンドユーザーは開発の決定に影響されません。キャピストラーノを例にとってみましょう。数ヶ月前、ジェイミスは開発への取り組みの終了を発表しました。コミュニティが開発を担当し、マスターリポジトリをjamis/capistranoからcapistrano/capistranoに移動しました。GEMがjamis-capistranoとしてリリースされたらどうなるでしょうか?すべてのユーザーは、多くの手間をかけて新しいGEMと新しいリポジトリに切り替える必要があります。

RubyForgeがメインのCapistrano配信ハブであり続けているため、このシナリオは発生しませんでした。

-

結論として、残念ながら、GEMの品質が全体的に低下していることに気づきました。これは主に、必要なレベルの知識がなくても、RubyやRubyGemsに近づく人が増えたことによるものです。同じことが多数のRailsプラグインにも当てはまります。

GitHubを原因としてラベル付けすることはできません。複雑なものがより簡単になり、基礎知識なしでより多くの人々がそれらに近づくとき、複雑さは自然淘汰プロセスであるため、品質が低下する可能性があるのは正常です。

とにかく、Rubyコミュニティにはまだ優れたレベルの品質があります。Ruby開発者がユニットテストやその他のプロのプログラミング習慣にどのように取り組んでいるかを見るのは驚くべきことです。

于 2009-07-20T10:04:21.103 に答える
4

私が知る限り違いはありません。

両方のソースからの宝石の品質/安定性には大きな幅があります。堅実なものもあれば、プレアルファ品質のものもあります。

それは、gem プロジェクト自体に大きく依存します。

とはいえ、github モデルは問題をより迅速に解決するのに適しています。プロジェクトをフォークし、バグを修正し、元のソースに含めるために提出する方がはるかに簡単です。したがって、少なくとも人気のあるプロジェクトでは、バグはより迅速に修正されます。そのため、プロジェクトがより早く成熟するのに役立つかもしれませんが、私にはわかりません。

于 2009-07-11T09:05:59.000 に答える
0

おそらく安定性が低く、少し最新です:) -r

于 2009-10-05T21:57:45.090 に答える
0

最終的にあなたの質問に答えるために:あなたが言及したリソース(rubyforge、github)は両方とも現在廃止されています.gemcutterは新しい唯一のrubygemsの場所です.

Gemcutter が新しい公式のデフォルト RubyGem ホスト: http://www.rubyinside.com/gemcutter-is-the-new-official-default-rubygem-host-2659.html

于 2010-01-20T05:30:15.600 に答える