1

バージョンに名前を付ける良い習慣を採用しようとしています。

プロジェクトのコーディングが完了しました。未知のバグが含まれている可能性があるため、「v1.0rc1」とタグ付けします。すべてのバグが見つかり、修正されたら、更新されたバージョンに「v1.0」のタグを付けます。

しかし、バグが見つからず、リリース候補が最終リリースに十分であることが判明した場合はどうなるでしょうか?

SCM を使用すると、最後のコミットに「v1.0」のタグを付けるのと同じくらい簡単です。

問題は、ディストリビューションの更新にあります。RubyGems を使用しています。バージョン番号をコードに格納するのが慣習です。gem (ディストリビューション) をビルドするとき、RubyGem はバージョン番号を gem のファイル名に入れ、それをリポジトリにアップロードします。

バージョン番号を変更してgemを更新すると、すべてのユーザーがディストリビューション全体をダウンロードせざるを得なくなり、何のメリットもありません。私はこれを悪い習慣だと考えています。

一方で、「v1.0rc1」を永遠に使い続けることも、バグを含む可能性のある最終バージョンをリリースすることも望んでいません。

リリース候補をステージングし、ユーザーに不要なリリースの再ダウンロードを強制しないようにする方法はありますか?

4

2 に答える 2

1

ここでの問題は、コードの変更がビルドのコンシューマーに適切に反映されないことです。消費者は、何が変更され、何が変更されていないか、およびこれらの変更の影響を知る方法がないため、すべてを再度ダウンロードする必要があります。

あなたができることは、製品を多くの小さな部分に分割して、ダウンロードが少なくなるようにすることです. しかし、これは、今日のダウンロード速度で数秒節約できるものを維持するための多大な努力です (あなたの製品は 400MB ではありませんよね?)。

最終的には、ハッシュとタイムスタンプを使用して何かが変更されたかどうかを判断するビルド システムを作成できるようになることを願っています。この情報は、ダウンロードに含まれるか、ダウンロードを提供するサーバーと依存関係管理システムに含まれる可能性があります。

  1. 変更された部分のみをダウンロードします（つまり、新しいバージョン番号を含む単一のファイル、またはそのファイル内の単一の定数の新しい値のみを含む）
  2. あなたのコードの変更が私のコードに影響を与える可能性があるかどうか、もしそうなら、どの部分に影響するかを判断してください。
于 2013-04-10T11:52:15.987 に答える