Clever Geek Handbook

早期リリースまたは成熟？

mutt



、 mplayer



、およびgzip



には、これらが高品質のオープンソースプロジェクトであるという事実以外に、一般的なものは何ですか？ ヒントとして、主要な質問をします： ウェブサイトでの公式発表の前に、Debian Linuxの次のバージョンのリリースの正確な月を教えてもらえますか？















これらのプログラムにはすべて、1つの機能があります-比較的長く予測不可能な開発とリリースのサイクルです。 その間、厳密にスケジュール通りに、 予測可能で比較的短いリリースサイクルがますます一般的になりつつあります。 どの開発戦略がより有利であり、最適な戦略への移行を達成するための条件は何ですか？ これについては、この記事で説明します。







より頻繁に、早期にリリースする



これは、 The Cathedral and the Bazaarの著者であるEric Raymondの有名な論文を翻訳したものです[1] 。 この本では、彼は古いUnixスタイルの開発を大聖堂と比較しています。これはLinuxの開発方法とはまったく対照的です。







このバザースタイルがうまく機能し、うまく機能することにショックを受けました。 私は個々のプロジェクトの開発に参加しただけでなく、Linuxの世界に無秩序がないだけでなく、大聖堂の建設者がvy望するだけの速度で前進している理由を理解しようとしました 。



この哲学はLinuxカーネル自体の開発を完全に特徴づけていますが、多くのオープンソースプロジェクトはそれを十分に評価しておらず、 アドホックリリース戦略を遵守していません。 そのため、特定の機能セットがコードに組み込まれ、安定したときに、準備ができたら新しいバージョンを展開するプロジェクト開発戦略を呼び出します。







Mplayer-aの最初の安定バージョンとして、このアプローチには重大な欠点があります 。 







  8414213 Oct 22 2006 MPlayer-1.0rc1.tar.bz2 57 Oct 22 2006 MPlayer-1.0rc1.tar.bz2.md5 3453 Oct 22 2006 MPlayer-1.0rc1.tar.bz2.torrent 9338201 Oct 7 2007 MPlayer-1.0rc2.tar.bz2 57 Oct 7 2007 MPlayer-1.0rc2.tar.bz2.md5 65 Oct 7 2007 MPlayer-1.0rc2.tar.bz2.sha1 3707 Oct 11 2007 MPlayer-1.0rc2.tar.bz2.torrent 9650074 May 29 2010 MPlayer-1.0rc3.tar.bz2 538 May 29 2010 MPlayer-1.0rc3.tar.bz2.asc 57 May 29 2010 MPlayer-1.0rc3.tar.bz2.md5 65 May 29 2010 MPlayer-1.0rc3.tar.bz2.sha1 12134661 May 29 2010 MPlayer-1.0rc3.tar.gz 538 May 29 2010 MPlayer-1.0rc3.tar.gz.asc 56 May 29 2010 MPlayer-1.0rc3.tar.gz.md5 64 May 29 2010 MPlayer-1.0rc3.tar.gz.sha1 10351350 Jan 29 2011 MPlayer-1.0rc4.tar.bz2 538 Jan 30 2011 MPlayer-1.0rc4.tar.bz2.asc 57 Jan 29 2011 MPlayer-1.0rc4.tar.bz2.md5 65 Jan 29 2011 MPlayer-1.0rc4.tar.bz2.sha1 12979618 Jan 23 2011 MPlayer-1.0rc4.tar.gz 538 Jan 30 2011 MPlayer-1.0rc4.tar.gz.asc 56 Jan 29 2011 MPlayer-1.0rc4.tar.gz.md5 64 Jan 29 2011 MPlayer-1.0rc4.tar.gz.sha1 11202492 May 5 2013 MPlayer-1.1.1.tar.xz


人気のあるレイアウトプラットフォームScribus



は、バージョン1.4.6をリリースしましたが 、1.4.0をリリースしました 。 2012年の初めに登場しました。 1.5.0がリリースされたとき、一般的には不明です。 GKHカーネルの安定したLinuxブランチのメンテナーの主な作業ツールである mutt



メーラーは、最も難しいもののために他の多くの人が入手できるバージョン1.5.Xにあります。 そして、 gzip



さえ1993年から2006年までのバージョン 1.2.Xと1.3.Xの間で13年間続きました。











同時に、大規模なプロジェクトは長い間タイムラインに移行しており、原則としてリリース間の間隔は6か月を超えていません。 新しいプロジェクト開発戦略を選択するためのいくつかの大規模なプロジェクト、時間間隔、および時間のリストを以下に示します。











Debianは独立しており、2つの戦略のハイブリッドな組み合わせです。 ご覧のとおり、Debianチームはまだスケジュールを順守していますが、開発サイクルは長すぎて、予測可能な生産サイクルで戦略を活用できません 。 かなり頻繁に、新しいバージョンのリリース日が遅れます。







不思議なことに、KDEプラズマ5では、 フィボナッチシーケンスの週である木曜日に .0バージョンがリリースされました。







FrameworksのPlasma .0タグは木曜日にリリースされ、火曜日にリリースされます。 2週間前の木曜日にベータタグ/リリース。 バグ修正タグ/リリースは、最初の1、1、2、3、5週間のフィボナッチ数列の.0リリース後の火曜日にあります。



アドホック戦略の支持者の長期的な構築の理由、予測可能な短い生産サイクルの利点、および前者を後者に変更する能力について考えてみましょう。







規律事項



特定の機能セットがコードに含まれ、新しいバージョンをリリースするために安定するのをチームが待っているとき、次のことが最も頻繁に起こります。 多くのプロジェクト愛好家が最近働いており、以前に新しい概念に出会ったことがないため、ある時点で、彼らはすべての望ましいイノベーションを追加しても機能しないことを認識しています。 その後、意志により、彼らは誰もがショックになる予定のリリース日を発表します。 多くのリリースが何年も見ず、それを行う方法を知らないため、これに続いてパッチとバニティの突風が続きます。







GitLabであるかどうかにかかわらず、開発者はスイス時計のように、毎月22日に新しいバージョンを公開します。 創設者でプロジェクトマネージャーのDmitry Zaporozhetsによると、すべてが完璧になるまで待たないでください。





GitLabでは、何かが完璧になるのを待つべきではないと考えています：持っているものをリリースし、スケジュール通りに実行します
予測可能なスケジュールと短いリリース間隔には、次の利点があります。









特に有利なのは、 アドホック戦略からGNOMEに影響されるチャートへの移行です。 ここに写真のヒキガエル、つまりGimp処理、Vasya Lozhkinの絵画「ひげのある生活」を追加する必要がありますが、残念ながらアーチで必要な言葉を美しく書くことはできません。







OpenStack



の非常に大規模で複雑な一連のオープンソースプロジェクトには6か月のリリースサイクルがありますが、最初は3か月ごとに新しいバージョンがリリースされました。 







 Release date Release name Oct 21st, 2010 Austin Feb 3rd, 2011 Bexar Apr 15th, 2011 Cactus Sep 22nd, 2011 Diablo Apr 5th, 2012 Essex Sep 27th, 2012 Folsom Apr 4th, 2013 Grizzly Oct 17th, 2013 Havana Apr 17th, 2014 Icehouse


OpenStack



数字を簡単に見てみましょう。









この巨大な取り組みのハイライトは、プロジェクトで協力しながら、主要な参加者が市場で互いに競い合うことです。 HPEはMirantisとRackspace、IBMとIntel、VMWareとCisco、RedHatとCanonicalと競合しますが、 OpenStack



、誰もが白くふわふわしています。











長い開発とリリースのサイクルに依存して、このプロジェクトがどのように発展するか想像してみてください。 予測可能で明確なタイムラインに固執するのではなく、一連の新機能の準備が整い次第、次のバージョンのリリースが発生した場合はどうなりますか？ この場合、参加者は何にも同意できず、プロジェクトは早い段階で停滞していたと思います。







キボノ？



上記のすべてのことは、例外なく、すべてのプロジェクトで、 ad-hoc



リリース戦略から予測可能なスケジュールへの移行が有益であることを意味していますか？







最初に思い浮かぶのは反例です。 vim



またはGNU Coreutils



があります。これらはめったにまたはあまり予測できないようにリリースされますが、それでもすべて開発およびユーザーベースで優れています。 問題は、オープンソースプロジェクトを成功させるために、新しいトレンドに敬意を表するために開発戦略を変更する正当な理由がないことです。 この知恵はすべての管理者に知られています： 作品-触れないでください 。







同様に、コミットがまったくない場合、 アドホックリリースから予測可能なリリースに切り替える理由はありません。 変化の臨界質量が蓄積されなければなりません。







FireFoxの例で示されているように、前述の2つの戦略とコードの品質の間に線形関係はありません 。 調査によると、予測可能な短い生産サイクルへの移行の前後で、安定バージョンのリリース後のバグの数はほぼ同じでした。











製品が属するユーザーセグメントを明確に理解することが重要です。 gcc



コンパイラは一つのことです。もしあなたがそれを早期に生で公開するなら、プログラマはファイルでそれを思い起こさせることができます。 これはまったく別のことです。ApacheWebサーバーは、事前に安定したバージョンをリリースするのは面倒です。







上記のすべてを要約します 。 次の場合は、 アドホックよりもチャートが適しています 。









使用材料



  1. オープンソースプロジェクトが時間ベースのリリースを採用する理由と方法
  2. フリーおよびオープンソース（FOSS）プロジェクトでの時間ベースのリリース管理
  3. 産業用フリー/リブレ/オープンソースソフトウェアエコシステムにソーシャルネットワーク分析を適用することから学んだ教訓
  4. OpenStack Wikiページ




↑ ロシア語翻訳の本 。 オリジナルでは、このフレーズは聞こえます： 頻繁にリリースし、早期にリリースします。


More articles:


All Articles