寿命が限られているバックポートブランチのコード品質
私と他の多くのパッケージメンテナーは、Julia 0.7（暫定リリース）と1.0で動作するようにパッケージをアップデートしました。
その際、Julia 0.6（以前の安定版リリース）のユーザーがホットフィックスやその他のバックポート機能を利用できるようにするバックポートブランチを作成することがよくあります。
これらのバックポートブランチは、コミュニティの大部分が移住するまで、最大で次の6か月間しか維持されません。
このような状況では、バックポートブランチでコード品質を維持することがどれほど重要かを示します。
特定の例：最近、3つのテストを含む新機能を追加しました。この機能をバックポートしましたが、必要なテストライブラリ機能がJulia 0.6で利用できないため、テストの1つしかバックポートできませんでした。
これでよろしいですか？これが永遠に続くとしたら、私が検出できないほど何かを壊したことを恐れずに、物事をバックポートすることはますます難しくなるだろうと感じています。
一方、これらのテストをバックポートするために必要な作業は正当化するのが難しいようです。バックポートされたブランチをそれほど長く維持するつもりはなく、少数の追加機能のみをバックポートするつもりだからです。ですから、一掃できるのは少しの技術的負債です。
「Xか月後には下落するので、気にしないでください」と聞くたびに1ドル持っていたら.....
しかし、あなたの場合、あなたはバージョンを維持する期間を決定する人ですそしてそれに投入する作業量。
- 0.6で、アップグレードに煩わされない有料の顧客をたくさん持っていますか？
- 古いバージョンに時間を費やすのに多くの費用がかかりますか？
- 1.0で作業する代わりに0.6/0.7を修正したために、新しい1.0バージョンがそれほど良くない場合、何が失われますか？
以下があなたの状況に完全に当てはまるかどうかを知るほどジュリアを知りませんが、比較可能な状況に対する一般的な答えを与えるために：私見それは2つの異なるコードを維持することを避ける良いアイデアです同じパッケージのベース数か月間。
ユーザーの大多数がまだJulia0.6を使用していて、たとえば6か月の期間にわたって使用すると予想される場合は、
0.6でも主な開発を行う
julia 1.0の feature-identical バージョンを提供しますが、言語の新しい機能を使用したい（少なくとも、0.6をサポートしたい期間）ことに抵抗します。
目標は、 1つのコードベースを持ち、両方の環境で98％を超えるコード行が同一であることです。ファイルは同一である必要があります。パッケージの0.6バージョンと1.0バージョンをビルドできるブランチをバージョン管理システムに2つ、1つだけ維持しないでください。もちろん、0.6と1.0では異なるビルド構成を維持する必要があるかもしれません。そして、明らかに他に方法がない場合は、いくつかの制限を回避するために少し条件付きコンパイルが必要になるかもしれません（ただし、コードのその部分を小さく保つようにしてください）。
そのルートをたどると、「バックポート」と「異なるコード品質」の問題は単純に発生しません。 「1.0」が利用可能になったからといって、信じられないほどの罠にはまらないでください。すぐに「最新かつ最高の」バージョンの環境を使用する必要があります。一部のユーザーが完全に切り替える前に数か月待つことができる、または待つ必要がある場合は、あなたもできると確信しています。
個人的な経験についてお話ししましょう。私たちのチームはこの戦略を1回使用して、約100kLOC C++プログラムを古いUI 16ビットフレームワークと古い16ビットBorlandコンパイラから新しいMSコンパイラを使用する新しい32ビットUIフレームワークに、約1年の時間枠で移植しました。 1つのコードベースで製品の「新しいバージョン」を維持し、2番目のコードベースで古いバージョン（「バックポート機能または修正」付き）を維持しようとした場合、タスクを管理できなかったと思います。
代わりに、コンパイラーとライブラリー環境の両方で同一のソースファイルをコンパイルできる状態にコードベースを維持するように管理しました。私たちは次のようないくつかの戦術を使わなければなりませんでした
新しい環境で古いAPIのラッパーをいくつか提供します（
std::stringの周りのStringラッパーなど）共通のソースファイルをハードリンクを使用して2番目のフォルダーにミラーリングし、コンパイルフォルダーを分離しますが、一方のフォルダー内のファイルを編集する場合、「もう一方のファイル」も自動的に変更されます
移行期間中は、新しいC++機能を使用したり、新しいライブラリを直接使用したりしないでください（ラッパーを使用する場合を除く）。
もちろん、これらのアイデアを環境や状況に反映させる必要がありますが、一般的な戦略が明確になれば幸いです。