バージョン管理ソフトウェアで現在の開発とメンテナンス開発を分離するために推奨される方法は何ですか？

Gitを使用して管理されているソフトウェアアプリケーションがあります。私は新しいバージョン2.xをリリースしました。これは長期的に維持する予定です（ほとんどのバグ修正）。それまでの間、バージョン3.xの作業を開始したいと思います。これを管理するための推奨される方法は何ですか？バージョン2.xのブランチを作成し、マスターで3.x開発を行う必要がありますか？または逆ですか？

ここで、非常に興味深い方法について説明しました。Gitブランチモデルの成功

とても興味深かったのですが、まだ実際に使っていません。

非常によく、記事が言っていることの（非常に）短い要約を要求したように：

• マスターブランチはすべて、完成したマイルストーン（バージョン1.0、1.1、1.2など）のみを表します
• 開発はそれ自身のブランチで行われます（誰が考えたでしょうか？機能の完全なバージョンが完了すると、開発ブランチはマスターブランチにマージされます。
• 開発からの分岐は機能分岐です。これらは、次の（または将来の）リリースの単一の機能を表しています。それらは、developブランチにマージされます。
• 開発に由来する別のブランチは、「リリース」ブランチです。これは、ほぼ完全なリリースバージョンを表すブランチで、細かい部分だけをクリーンアップする必要があります。開発ブランチとマージし、最終的にはマスターブランチとマージします。
• "Hotfix"ブランチは、リリースの1つに重大なバグが見つかった場合にマスターブランチからブランチします（つまり、「使用によりコナミコードが入力された場合、プログラムはメインハードドライブを再フォーマットします...」）。バギーリリースから分岐し、修正が完了すると、マスターブランチと開発ブランチにマージされます。

それはそれでは不十分ですが、信頼できる記事です。この記事ではそれをより詳細に説明し、わかりやすい視覚化グラフィックを使用すると、はるかに理解しやすくなります。

私の原則は、ブランチが短期間であるほど、ブランチ構造のより深いところにあり、その名前がより具体的になるということです。ブランチの期間が長くなるほど、ブランチ構造内の浅くなり、その名前はより一般的になります。

したがって、マスターを長期（3.X）バージョンの間保持し、このブランチに特定の名前（リリースコード名またはさらに悪いリリース番号）ではなく、一般的な名前（マスター、トランク、開発など）で名前を付け続ける後のマーケティング決定に実際に依存しすぎている）

ブランチのフラットな名前空間があり、ブランチが同等であるgitのようなシステムではそれほど重要ではありません。ブランチの階層的な名前空間を持つclearcaseのようなシステムの方が重要です（V4ブランチの完全な名前は、最終的にmain / v1 / v2 / v3 / v4 ...になります）。