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

私のjarを使用するすべてのJavaプロジェクトは、ほぼ確実に、私のjarにも依存関係として含まれている別のjarへの追加の依存関係があります。 問題は、他のjarに複数のバージョンがあることです。 プロジェクトの2番目のjarのバージョンが私のjarの2番目のjarのバージョンと異なる可能性が高い場合に、発生する可能性のある問題を回避するにはどうすればよいですか？ 私のjarファイルを追加するために、ユーザーが特別なクラスローディングトリックを実行するという面倒なことをしたくありません。 その共通の依存関係のすべての可能なバージョンについて、jarのさまざまなバージョンの束を作成する必要がありますか？そして、あなたはちょうどあなたがたまたま持っている2番目のjarの同じバージョンを使用する私のjarのバージョンを選択するだけですか？ これを処理するよりスマートな方法はありますか、そして人々が衝突することなく私のjarをより簡単に使用できるようにしますか？

10 java  patterns-and-practices  versioning  project-structure  dependencies 

5つの主要なコンポーネントで構築されたプログラムがあります。各コンポーネントのバージョンを確認したいので、標準のバージョン番号は制限が多すぎると思います。 誰かが個別にリストする以外に、これを行う簡単な方法を見つけた人はいますか？

10 versioning 

14日間のスプリントの反復があり、新機能、いくつかの改善点、および修正すべきバグのストーリーがいくつかあるとします。また、準備が整ったときにこれらの変更をデプロイします。スプリントの終了を待ちません。 私の問題は、このように開発および保守された製品のセマンティックバージョニングを追跡する方法ですか？14日ごとにリリースされる場合は簡単ですが、バージョン番号を増やし、すべての変更を変更ログに記録します。しかし、変更が継続的にデプロイされるとどうなるでしょうか。何かがデプロイされるたびにバージョンを上げる必要がありますか？または、スプリントが終了するまで待ってから、「再開」して、実際の展開で独立して反復ごとに1回だけバージョン番号を増やす必要がありますか？アジャイルのセマンティックバージョニングのベストプラクティスは何ですか？ 編集：私のニーズをよりよく説明するために、私は最初に利害関係者の変更ログを求めています。変更がデプロイされるたびに、変更ログの新しいレコードに関心を持つことはないと思います。

10 agile  scrum  versioning 

現在サーバーへのWebインターフェースのみをサポートしている既存のアプリケーションを補足するために、ネイティブモバイルアプリケーションのスイートを構築しています。アプリケーションは、クライアントが独自のインフラストラクチャにインストールしてホストすることも、それを利用したいクライアントのために自分でホストすることもできます。大企業のお客様は通常、セルフホスティングを選択しましたが、小規模のお客様はホスティングオプションを選択しました。 アプリケーションの複数のバージョンをサポートする必要があります。すべてのお客様が同時にアップグレードを希望するわけではありません。Webインターフェイスでは、サーバーのインストールに関連付けられたサーバーバージョンがWebインターフェイスで自動的に使用されるため、複数のバージョンのサポートは難しくありません。通常、App Storeで利用できるアプリが1つしかないモバイルアプリケーションでは、モバイルアプリでのさまざまなレベルのサーバーAPIと機能のサポートが課題になります。他の人が問題をどのように解決しているか知りたいです。私の心には、次のようなオプションがあります。 アプリストアでアプリの複数のバージョンをサポートします。 モバイルアプリケーションにサポートを組み込み、通信しているサーバーのAPIバージョンを自動的に決定し、関連するサーバーAPIエンドポイントに呼び出しをルーティングします。また、サーバーのさまざまなバージョンで利用できる機能に基づいて、モバイルアプリケーションの機能を有効/無効にするために、ある種の機能切り替えメカニズムを使用することも紹介します。 アプリのデプロイにアプリストアを使用しないでください。アプリのダウンロードとインストールに使用できるバージョン固有のURLをユーザーに示します。 オプション1 -IMOはアプリのユーザーを混乱させます。また、実際には2つの独立したアプリケーションであるため、あるバージョンのアプリから次のバージョンへの移行パスは適切ではありません。 オプション2-一方、UIビジュアルは、基本的に、通信しているサーバーAPIのバージョンで利用可能な機能に適応する必要があることを考慮すると、すぐに非常に複雑になる可能性があります。また、必要なサーバーAPI呼び出しのさまざまなバージョンをサポートする必要があります。 オプション3-アプリのサイドローディングを行う場合、Androidの世界で可能ですが、私の知る限り、iOSではサポートされておらず、今後のWindows 10モバイルアプリの画像はどのようになるかわかりません。 この問題に取り組むために他にどのようなアプローチがありますか？私たちがネイティブアプリを作成しているという事実について議論しないでください。それは私が求めていることではありません。サーバーAPIの異なるバージョンと通信する同じネイティブモバイルアプリの複数のバージョンをサポートする問題に他の人々がどのように取り組んでいるのかについてのガイダンスを探しています。

10 mobile  deployment  versioning 

イベント駆動型マイクロサービスアーキテクチャの変更を処理するためのオプションを調査している調査プロジェクトを行っています。 したがって、4つの異なるサービスを利用できるアプリケーションがあるとします。これらの各サービスには、ローカルデータを格納するための独自のデータベースがあります。 このセットアップでは、4つのサービスがイベントバスを使用して相互に通信します。したがって、サービスで何かが発生すると、イベントが発行されます。そのイベントに関心のある他のすべてのサービスは、独自の方法で処理します。 その場合、アーキテクチャー内のさまざまなサービスは、これらのイベントの内容（属性など）について「契約」を持つ必要があります。したがって、サービスはこれらのイベントに「疎結合の依存関係」を持っています 私の質問は次のとおり です。これらのイベントの変更をどのように処理できますか？ それでは、サービスAがアプリケーションに新しいユーザーを登録するとします。したがって、 "" UserRegistered "イベントを送信します。サービスBがそのイベントを取得して処理します。ただし、サービスチームCの一部の開発者は、登録済みユーザーの性別も必要であると判断しました。そのため、イベントが変更され、属性gender 「UserRegistered」イベントに追加されます。 サービスBが再デプロイせずに、その追加属性を使用して同じイベントを引き続きピックアップできることをどのように確認できますか？ そして、この問題に取り組み、これらのイベントをバージョン管理する他の方法はありますか？

9 communication  versioning  microservices  message-queue  code-contracts 

私はGitの広い世界に慣れていません。私はマニュアルを読んで練習してきましたが、検索してみて理解できなかったいくつかの点について混乱しています。 不思議なんだけど： プロジェクト（最初のコミット後）で、ソースファイルをステージングする適切なタイミングはいつですか？コミットする直前？追加/削除または変更した直後ですか？ ファイルが2つのコミットの中間でステージングされ、その後変更された場合、Gitはどうなりますか？それが述べられたときのコンテンツの変更とそれ以降の内容について注意する必要がありますか？ 新しいファイルを作成し、それをステージングしてから削除したい場合、Gitが「-f」フラグを使用するように求め、単純な「git -rm file.ext」が機能しないのはなぜですか？ 「ステージの意味」など、Gitのマニュアルやその他のチュートリアルのさまざまな主題を読みましたが、前述のように、上記のことはまだわかりません。 ですので、できれば、自分の言葉と例を使って質問に答えてください。そうすれば、理解しやすくなるでしょう。 ありがとうございました。

9 version-control  git  versioning 

新しい開発を開始する前にバージョンをバンプするプロジェクトもあれば、リリースにタグを付けるときにバージョンをバンプするプロジェクトもあります。 どちらのアプローチが優れていますか？ 新しいフェーズの開始時にバージョン番号が変更されていない場合、開発者はバージョン番号を変更するのを忘れて、プログラムをリリースするだけです。 リリースにタグを付ける前にバージョン番号が変更された場合、バージョン番号（タグとMakefile / AssemblyInfo.cs）は一致しません。 git describe 現在のリビジョンがv1.2.3.4より後の場合、v1.2.3.4-15-g1234567が表示されることがありますが、ファイルはすでにv1.2.3.5に変更されています。

9 version-control  versioning 

APIベースでサポートされている大規模なプロジェクトがあるとします。このプロジェクトには、エンドユーザーが使用できるパブリックAPIも含まれています。 場合によっては、プロジェクトをサポートするAPIベースに変更を加える必要があります。たとえば、APIの変更や新しいメソッドを必要とする機能を追加したり、APIとの間でやり取りされるオブジェクトの1つまたはオブジェクトの1つの形式を変更したりする必要がある機能を追加する必要があります。 パブリックAPIでこれらのオブジェクトも使用していると仮定すると、パブリックオブジェクトもこれを実行するたびに変更されます。これは、クライアントが解析コードを機能させるために同一のままであるAPIオブジェクトに依存する可能性があるため望ましくありません。（咳C ++ WSDLクライアント...） したがって、解決策の1つは、APIをバージョン管理することです。しかし、APIの "バージョン"と言うと、これは、変更されたメソッドシグネチャごとに重複したメソッド呼び出しを提供するだけでなく、APIオブジェクトをバージョン化することも意味しているように思えます。したがって、APIのバージョンごとにプレーンな古いclrオブジェクトを作成しますが、これもまた望ましくないようです。そして、たとえこれを行っても、膨大な量の重複したコードが作成されることになるため、各オブジェクトを最初から構築することはありません。むしろ、APIはベースAPIに使用しているプラ​​イベートオブジェクトを拡張する可能性が高いですが、追加のプロパティが想定されていないときにパブリックAPIでも使用できるため、同じ問題が発生します。 では、この状況に通常適用される正気とは何でしょうか？Git for Windowsなどの多くのパブリックサービスがバージョン管理されたAPIを維持していることは知っていますが、バージョン管理されたさまざまなメソッドや入出力オブジェクトをカバーする膨大な量の重複コードなしでこれをサポートするアーキテクチャを想像するのに苦労しています。 セマンティックバージョニングなどのプロセスは、パブリックAPIのブレークが発生したときに何らかの健全性を提供しようとすることを知っています。問題は、オブジェクトが分離されていない場合、多くの変更またはほとんどの変更でパブリックAPIを解除する必要があるように見えることですが、コードを複製せずにそれを行うには良い方法がありません。

9 versioning  api-design 

以前は、@DeprecatedAPIバージョンにアノテーションを追加する標準的な方法を使用していましたが、今後のバージョンでは削除されます。 現在、ライブラリのメジャーバージョンを準備しています。多くのAPIパーツが削除され、名前が変更されています。 既存のユーザーが簡単に移行できるようにするには、新しいライブラリバージョンを古いバージョンと並べて使用できると便利な場合があります。 メリット バージョン間の動的切り替えを実装できます 新しいバージョンでバグが見つかった場合、アプリケーションは前のバージョンにフォールバックできます（ベータ段階で役立ちます） これを行うために、私は単純に新しいパッケージに新しいライブラリのバージョンを移動することができcom.mycompany.libraryへcom.mycompany.library.v2 これは一般的な方法ですか、それともこのようなJavaライブラリの並列使用について他の推奨事項がありますか？ バックグラウンド： ライブラリはシンプルなドキュメントコンバーターです。そのため、convert（in、out）メソッドのほかに、多くの構成プロパティといくつかのイベントハンドラーがあります。サイドバイサイドの使用法を提供する場合、コンシューマーはそれらを動的にインスタンス化して構成できます。 if (useVersion2) { com.mycompany.library.v2.Converter c = new com.mycompany.library.v2.Converter(); // configure and run c.setOption(...); c.convert(in, out); } else { com.mycompany.library.Converter c = new com.mycompany.library.Converter(); // configure and run c.setOption(...); c.convert(in, out); } （質問は/programming/37192945/から移動しました）

8 java  api-design  libraries  versioning 

イベントソーシング、CQRS、マイクロサービスを使用するシステムを設計しています。これは珍しいパターンではないことを理解しました。このサービスの重要な機能は、記録システムから再水和/復元する機能である必要があります。マイクロサービスは、MQ（Kafka）でコマンドとクエリを生成します。他のマイクロサービスが応答します（イベント）。コマンドとクエリは、監査と復元の目的でS3に保持されます。 現在の思考プロセスは、システムを復元するために、S3からイベントログを抽出し、単純にKafkaにフィードバックできるというものでした。 しかし、これは時間の経過に伴う生産者と消費者の両方の変化を認めることができません。コマンド/クエリレベルでのバージョン管理は、問題の解決にある程度役立つようですが、復元中のコマンドが受信および処理されたときに、まったく同じになるようにコンシューマーのバージョン管理を行うことはできません。 [のバージョン]コマンドを最初に受信したときに処理を実行しているコード。 これを解決するために使用できるパターンはありますか？この機能を宣伝する他のシステムを知っている人はいますか？ 編集：例を追加します。 「バイヤー」が私のオークションサイトの「セラー」に「質問」を送信します。フローは次のようになります。 UI -> Web App: POST /question {:text text :to seller-id :from user-id} Web App -> MQ: SEND {:command send-question :args [text seller-id user-id]} MQ -< Audit: <command + args appended to log in S3> MQ -< Questions service: - Record question in DB …

8 versioning  cqrs  event-sourcing  microservices  apache-kafka 

WCFサービスとメインLib1を持っています。 たとえば、Save Profile Serviceがあるとします。WCFはクライアントからデータ（事前に定義されたデータコントラクトを含む）を取得し、それをメインクラスLib1に渡し、応答を生成してクライアントに送り返します。 WCFメソッド：SaveProfile（ProfileDTOプロファイル） 現在のバージョン1.0 ProfileDTOには、次のUserName Password FirstName DOBがあります（文字列yyyy-mm-dd）CreatedDate（文字列yyyy-mm-dd） 次のバージョン（V2.0） ProfileDTOには、次のUserName Password FirstName DOB（UnixTimeStampの場合）CreatedDate（UnixTimeStampの場合）があります。 バージョン3.0の ProfileDTOには次のものがあります（ユーザー名とパスワードの長さの検証が変更されています）UserName Password FirstName DOB（UnixTimeStampの場合）CreatedDate（UnixTimeStampの場合） 簡単に言うと、各バージョン1の間でDataContractとワークフローが変更されています。WCFサービスとメインクラスLib1のメソッドに名前を付けるにはどうすればよいですか？2.開発と保守を容易にするために、特定のパターンを使用する必要がありますか？3.バージョンごとに異なるエンドポイントが必要ですか？ 上記の例では、「SaveProfile」という名前のメソッドがあります。「SaveProfile1.0」、「SaveProfile2.0」などのメソッドに名前を付ける必要がありますか。バージョン「3.0」と「4.0」の間で変更がない場合、メンテナンスが困難になります。メンテナンスを容易にするのに役立つアプローチを探しています

8 wcf  versioning 

AとBという2つのアプリケーションがあります。これらのアプリケーションの現在のバージョンは7.xです（7.1を実行している顧客もいれば、7.2を実行している顧客もいます）。両方のアプリケーションは、次のように同じ共通フレームワーク（これをCと呼びます）を使用します。 +---+ +---+ | A | | B | +---------+ | C | +---------+ 重要な新規顧客がいるため、AとBの機能を1つの大きなアプリケーションにしたいと考えています。AとBを1つのアプリケーションにマージすることは不可能なので、今はAの機能をBに統合しようとしています。これまでのところ良好ですが、いくつかの問題が発生し始めています。 まず、Bの基本機能のみを使用する顧客は、追加されたAのすべての新機能に関心がない（そして、追加のオーバーヘッドが発生する）。彼らは、新しいWindowsバージョンをサポートしてバージョンBをアップグレードしたいだけで、C（共通フレームワーク）に追加されたすべての優れた機能も望んでいるだけです。 次に、現在アプリケーションAを使用している顧客は、アプリケーションBに直接移動したくありませんが、A + Bの機能を組み合わせることで、長期的には役立ちます。アップグレードを簡単にするために、彼らはAを使い続けたいと思っています。 3番目に、Bで行っているすべての開発は、Bのモジュールのパフォーマンスを向上させるために共通層CEgに影響を与える可能性があるため、Cのモジュールをリファクタリングする必要がありますが、CはAでも使用されているため、もっと多くの仕事をする必要があります。さらに、Aは古い、あまり構造化されていないアプリケーションであり、Cのすべての変更はAをより不安定にする可能性があります。 問題はどのように進めるかです。私は現在、7.xリリースでBを分割することを考えています（必要に応じて、ここでいくつかのマイナーな開発とリリース7.3、7.4を今後数年で行うことができます）、および8.xリリース（すべての新機能が含まれます）。 。共通層の問題を解決するために、Cを古いC（7.x）と新しいC（8.x）に分割することもできます。これにより、次の結果が得られます。 +-------+ +-------+ +-------+ | A 7.x | | B 7.x | | B 8.x | +-----------------+ +-------+ | C 7.x | | C 8.x | +-----------------+ +-------+ アプリケーションAはもう進化せず、7.xバージョンの共通レイヤーCに固執します。 …

8 versioning  release-management 

開発中のアプリケーションにバージョンを設定するロジックは何ですか？ 1.0から1.1または1.7から2.0を意味します

8 versioning 

私が維持しているプログラムの制限の1つは、エンドユーザーは多くの場合、どのような変更が加えられたかを知らないことです。これを修正するために、プログラムに加えられた変更の簡略化されたリストをユーザーに示したいと思います。更新が簡単なリストを作成し、それをユーザーインターフェイスにフィードできるようにするための適切な方法論/アプローチはありますか？ 例：フォームに読み込まれるすべてをXMLファイルに保存する必要がありますか？変更履歴をデータベースに入れるべきですか？ 注：プログラムはWinforms（C＃4.0）です。 更新 優れたフィードバックに基づいて、SQLiteを情報ストレージとして使用することを決定し、ユーザーにTreeViewコントロールの変更の時系列リストを提供します。

8 versioning  users 

本質的にXML文字列としてデータベースに保存されるオンラインドキュメントがあります。 ユーザーのためにドキュメントのバージョン管理を実装する方法を考えています。そのユーザーはドキュメントの以前のバージョンに戻ることができます。 更新私の場合、何十万ものユーザーがいるWebアプリケーションです。ユーザーは無制限のドキュメントを保存できます。ドキュメントのXMLは、MySQLのBlobフィールドに格納されるため、小さくはありません。結局、私はどういうわけか限界を制限する必要がありますが、それはすべて一緒に異なるトピックです。 これにアプローチする標準的な方法はありますか？バージョン間の違いのみを保存する必要がありますか？他に考慮すべきことは何ですか？

8 design  architecture  versioning