製品の最初のバージョンをリリースすると、ジレンマに直面する。新しいリリースに向けて開発を進めながら、どうやって最初のバージョンを維持するか。この問題に直面して、Target Processの設立者でCEOのMichael Dubakov氏(source)が、「プロジェクトで並行して複数のリリースとイテレーションを持つべきか」(source)の中で彼らの経験を書いた。
この場合、Michael氏はバージョン1.0を修正する必要があり、1.5を開発中で、2.0では新しい機能を開発したいと思っていた。1つのプロジェクトだから、1つのチームでよいだろうか? そのようなチームで、2.0のリリースに何人かの開発者と1.5に他の開発者を割り当て、1.0の重大な不具合を修正するために(生け贄の開発者として)Joe氏から時間を盗むのか？Michael氏は、無駄を最小限にして2.0には取り掛からないことにした。すべての開発者が1.5に重点的に取り組んでマルチタスクを減らし、できるかぎり決定を遅らせていた。(結局、2.0に必須の機能は2.0が近づいてくると必須ではなくなっているかもしれない。)
Steve Campbell氏(source)の経験では、この問題は、すべての作業(すべてのバージョンの)を1つのスプリントバックログに入れることによってもっともうまく解決できる。結果として、どのチームメンバも1つのタスクを引き受け(どのリリースのものであっても)、それに取り掛かることができる。Steve氏はこの状況でのブランチの戦略について議論を続ける。まったくブランチを使わないか (バージョンを区別するのにランタイムスイッチを使う)、主に書き換えを行っているコンポーネントのみブランチにする。
Eclipse Software Systems IncのMatt Swaffer氏(source)は、まったく異なるアプローチを使う。彼のチームはパッチリリースを出さない。代わりに彼らのゴールはトランクの安定性を維持することである。不具合修正が必要な場合、顧客はただ最新のビルドをダウンロードするように勧められる。その上、彼らはリリースごとにタグ付けをして重大な不具合が発見された場合、修正するために戻ることができる。彼の究極のゴールは毎週リリースすることである。
1つのコードストリームから複数の製品をリリースする問題に関して、Implementation Patterns(source)の著者、Kent Beck氏(source)は、彼が取り組んだ2つのプロジェクトについて語っている。そのプロジェクトでは、7つの取引先をサポートしなければならなかった。各プロジェクトはコアとなるロジックに加えて、顧客用のコードがあった。1つのプロジェクトでは、各顧客ごとに別々のコードを保持する。新しい顧客を獲得したとき、もっとも新しいブランチから複製して開発を続ける。Kent氏が言及しているように、彼らはマージの重圧に耐えられなくなっていく。もう一方のプロジェクトでは、1つのバイナリがすべての顧客に渡される。この場合、彼らは、顧客用のコードの正しい部分のみを各顧客が確実に実行する方法を見つけた。Kent氏の意見で重要な違いは以下の通りである。
2つの事例の重要な違いは、結合を遅らせる方法を見つけることにあります。それは原則を選ぶことから始まったのだと私は気づきました。原則とは、1つのコードベースを持つことにするというものです。これは、一部の設計オプションを排除することになりますが、まだ多くが残されています。別の重要な原則は、最初のケースでは、いくらか重複するコードを持つことを気にしないということです。どのように重複をなくすかはっきりしている場合、そうします。しかし、はっきりするまで待っても構わないと思います。
最後に、N-BRAIN(サイト・英語)のJohn A. De Goes氏(source)は言う。
ブランチは一種の無駄であり、ゴールはブランチを減らすこと、1つのコードストリームに移動すること、もっとも最近リリースされたバージョンが唯一サポートするバージョンであり、リリースごとに強制的にすべてインストールさせること、それもできるかぎり頻繁に起こるリリース (理想を言えば、1つの機能/不具合ごとに1リリース)でそうさせることです。これらすべては、SaaSでずっと簡単に行うことができます。
原文はこちらです：http://www.infoq.com/news/2008/06/multiple_versions