タグ付けされた質問 「versioning」

ソフトウェアのバージョン管理は、一意のバージョン名または一意のバージョン番号をコンピューターソフトウェアの一意の状態に割り当てるプロセスです。特定のバージョン番号カテゴリ（メジャー、マイナー）内では、これらの番号は通常、昇順で割り当てられ、ソフトウェアの新しい開発に対応しています。

6
「下流」と「上流」の定義
私はGitを使い始めて、「上流」と「下流」という用語に出会いました。私はこれらを以前に見たことがありますが、完全には理解していません。これらの用語は、SCM（ソフトウェア構成管理ツール）およびソースコードのコンテキストで何を意味しますか？
7
APIバージョン管理のベストプラクティスは？[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 6年前休業。 ロックされています。質問はトピックから外れていますが、歴史的に重要であるため、この質問とその回答はロックされています。現在、新しい回答や相互作用を受け入れていません。 WebサービスREST APIバージョン管理の既知のハウツーまたはベストプラクティスはありますか？ AWSがエンドポイントのURLによってバージョン管理を行うことに気づきました。これが唯一の方法ですか、それとも同じ目標を達成する他の方法はありますか？複数の方法がある場合、それぞれの方法のメリットは何ですか？
877 rest  versioning 
24
クライアントにJavaScriptファイルの更新を強制するにはどうすればよいですか？
現在、プライベートベータ版で作業しており、かなり急速な変更を行っている段階です。ただし、使用量が増加し始めているため、このプロセスの速度は遅くなります。そうは言っても、私たちが遭遇している1つの問題は、新しいJavaScriptファイルで更新をプッシュした後でも、クライアントのブラウザーがファイルのキャッシュバージョンを使用し、更新が表示されないことです。明らかに、サポートコールではctrlF5、サーバーに最新のファイルを確実に取得するために更新するように通知するだけですが、その前に処理することをお勧めします。 私たちの現在の考えは、JavaScriptファイルの名前にバージョン番号を添付し、変更が加えられたときに、スクリプトのバージョンをインクリメントしてすべての参照を更新することです。これで間違いなく仕事は終わりますが、リリースごとにリファレンスを更新するのは面倒です。 私たちがこれに対処する最初のものではないと確信しているので、私はそれをコミュニティに捨てるだろうと考えました。コードを更新するときに、クライアントがキャッシュを確実に更新するようにするにはどうすればよいですか？上記の方法を使用している場合、変更を簡素化するプロセスを使用していますか？
16
Subversionのコミットされていない変更を一時的に片付けます（「git-stash」のように）
Subversionリポジトリに格納されたソフトウェアをプログラミングしているときに、いくつかのファイルを変更することがよくあります。その後、メインの作業のためにいくつかの準備的な変更を行いたいことに気づきます。たとえば、新しい機能を実装しているときに、いくつかのリファクタリングが役立ちます。 2つの無関係な変更を混合しないように、これらの場合、変更を「格納」します。つまり、リポジトリバージョンに戻し、他の変更をいくつか行い、これらをコミットしてから、変更を「フェッチバック」します。 git-stashはまさにそれを可能にします。直接、またはプラグインやスクリプトを使用して、Subversionでこれを行う方法はありますか？Eclipseプラグインも問題ありません。
312 svn  versioning 
15
.NETのAPIを壊す変更への決定的なガイド
.NET / CLRでのAPIのバージョン管理、特にAPIの変更がクライアントアプリケーションに影響する、または影響しない方法に関する情報をできるだけ多く収集したいと考えています。まず、いくつかの用語を定義しましょう： APIの変更 -パブリックメンバーを含む、タイプの公に見える定義の変更。これには、タイプとメンバー名の変更、タイプの基本タイプの変更、タイプの実装済みインターフェースのリストからのインターフェースの追加/削除、メンバーの追加/削除（オーバーロードを含む）、メンバーの可視性の変更、メソッドとタイプパラメーターの名前変更、デフォルト値の追加が含まれますメソッドパラメーター、型とメンバーの属性の追加/削除、および型とメンバーのジェネリック型パラメーターの追加/削除（何か見落としましたか？）これには、メンバー組織の変更やプライベートメンバーの変更は含まれません（つまり、リフレクションは考慮されません）。 バイナリレベルのブレーク -APIの変更により、古いバージョンのAPIに対してコンパイルされたクライアントアセンブリが、新しいバージョンで読み込まれない可能性があります。例：メソッドシグネチャを変更します。以前と同じ方法で呼び出すことができます（例：voidでタイプ/パラメータのデフォルト値のオーバーロードを返す）。 ソースレベルのブレーク -APIの変更により、古いバージョンのAPIに対してコンパイルするように記述された既存のコードが、新しいバージョンでコンパイルされない可能性があります。ただし、コンパイル済みのクライアントアセンブリは以前と同様に機能します。例：以前はあいまいでなかったメソッド呼び出しにあいまいさをもたらす可能性がある新しいオーバーロードを追加します。 ソースレベルの静かなセマンティクスの変更-APIの変更により、古いバージョンのAPIに対してコンパイルするように作成された既存のコードは、たとえば別のメソッドを呼び出すことによって、そのセマンティクスを静かに変更します。ただし、コードは警告/エラーなしでコンパイルを続行し、以前にコンパイルされたアセンブリは以前と同様に機能するはずです。例：既存のクラスに新しいインターフェースを実装すると、オーバーロードの解決時に別のオーバーロードが選択されます。 最終的な目標は、可能な限り多くの破壊的で静かなセマンティクスAPIの変更をカタログ化し、破壊の正確な影響と、影響を受ける言語と影響を受けない言語を説明することです。後者について詳しく説明します。一部の変更はすべての言語に普遍的に影響します（たとえば、新しいメンバーをインターフェイスに追加すると、そのインターフェイスの実装が任意の言語で機能しなくなります）。これには、最も一般的にはメソッドのオーバーロードが含まれ、一般に、暗黙的な型変換に関係するすべての処理が含まれます。CLS準拠の言語（つまり、少なくともCLI仕様で定義されている「CLSコンシューマー」のルールに準拠している言語）であっても、「最小公分母」を定義する方法はないようです。ここで誰かが私を間違っていると訂正してくれれば感謝します-したがって、これは言語ごとに行われる必要があります。最も興味深いのは、当然、.NETに付属しているもので、C＃、VB、F＃です。しかし、IronPython、IronRuby、Delphi Prismなどのその他のものも関連します。それがコーナーケースであるほど、それはより興味深いものになります-メンバーの削除などのことはかなり自明ですが、たとえばメソッドのオーバーロード、オプション/デフォルトのパラメーター、ラムダ型の推論、および変換演算子の間の微妙な相互作用は非常に驚くことができます時には。 これをキックスタートするいくつかの例： 新しいメソッドオーバーロードの追加 種類：ソースレベルの区切り 影響を受ける言語：C＃、VB、F＃ 変更前のAPI： public class Foo { public void Bar(IEnumerable x); } 変更後のAPI： public class Foo { public void Bar(IEnumerable x); public void Bar(ICloneable x); } 変更前に機能し、その後壊れたサンプルクライアントコード： new Foo().Bar(new int[0]); 新しい暗黙の変換演算子のオーバーロードを追加する 種類：ソースレベルの区切り。 影響を受ける言語：C＃、VB 影響を受けない言語：F＃ 変更前のAPI： public …
12
ベストプラクティス：ソフトウェアのバージョン管理[終了]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 6年前休業。 ロックされています。質問はトピックから外れていますが、歴史的に重要であるため、この質問とその回答はロックされています。現在、新しい回答や相互作用を受け入れていません。 余暇に開発したソフトウェアを楽しくバージョン管理するためのガイドラインや標準的なベストプラクティスはありますが、それでも一部の人々はこれを使用しますか？私はあなたがバージョン1で話していることを知ることができるようにそのようなソフトウェアをバージョン管理する必要があると思います（例えば、バグ修正、サポートなど）。 しかし、バージョン管理はどこから始めればよいですか？0.0.0？または0.0？そして、どうやって数字を増やすのですか？メジャーリリース、マイナーチェンジ？そして、バージョン管理システムへのコミットは別のバージョンであるべきではありませんか？それとも、生産的な方法で使用されるバージョンのみですか？
211 versioning 
5
アセンブリのバージョン番号を維持するためのベストプラクティス/ガイダンス
.NETアセンブリの3つの異なるアセンブリバージョン番号を管理する方法について、ポインタ、提案、さらにはディクテーションを探しています。これは通常ビジネスによって決定されるように思われるので、製品バージョンは最も単純です。次に、ファイルバージョンはデプロイメント間のバージョン管理用のようで、実際のアセンブリバージョンは出荷時にのみ使用されます。 現在は、依存しないアセンブリのテストおよびメンテナンスリリースにラベルを付ける簡単な方法を探しているだけなので、ファイルバージョンの自動インクリメントビルド番号とリビジョン番号を調べ、最終リリースでは、現在のバージョンをコピーしていますファイルバージョンからアセンブリバージョンへ。製品は本番稼働中ですが、まだ開発中です-ご存知のように-小さな会社の1つであり、変更管理インフラストラクチャの状況はありません。
4
Intellijで別のsubversionブランチに切り替えるにはどうすればよいですか？
IntelliJでブランチを切り替える概念は何ですか？私は盲目かバカに違いない... 「コピーに切り替える」オプションなどがあると思いますが、ありません... 明確化のための編集：私の以前のIDEには、現在のブランチ/トランクとは異なるすべてのファイルを更新する単純な「コピーへの切り替え」オプションがありました。IntelliJはこれに対して完全に異なるアプローチを持っているようですが、私はそれを理解していないようです。ヘルプもあまり役に立ちません。 役立つキーワード、リンク、ヒントは大歓迎です。ありがとう。
7
RailsルートのAPIバージョニング
StripeのようにAPIをバージョン管理しようとしています。以下に、最新のAPIバージョンが2であることを示します。 /api/users に301を返します /api/v2/users /api/v1/users バージョン1で200のユーザーインデックスを返します /api/v3/users に301を返します /api/v2/users /api/asdf/users に301を返します /api/v2/users つまり、指定されたバージョンが存在しない限り、基本的に、バージョンを指定しないものは最新のものにリンクし、リダイレクトされます。 これは私がこれまでに持っているものです： scope 'api', :format => :json do scope 'v:api_version', :api_version => /[12]/ do resources :users end match '/*path', :to => redirect { |params| "/api/v2/#{params[:path]}" } end
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.