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

現在、共有リポジトリにPHPアプリケーションのマスターブランチが1つあります。当社のソフトウェアの加入者であるクライアントは500人を超えており、そのほとんどが異なる目的のために、それぞれ個別のブランチにカスタマイズされています。カスタマイズは、異なるテキストフィールド名、まったく新しい機能またはモジュール、またはデータベース内の新しいテーブル/列にすることができます。 私たちが直面する課題は、これらの数百のカスタマイズされたブランチを維持し、クライアントに配布する際に、時々新しい機能を提供し、マスターブランチを更新し、更新するためにマスターブランチの変更をカスタムブランチにプッシュすることですそれらを最新バージョンに。 残念ながら、これによりカスタムコードで多くの競合が発生することが多く、すべての競合を解決するためにすべてのブランチを何時間も費やしています。これは非常に非効率的であり、これらの競合を解決する際に間違いは珍しくありません。 クライアントブランチをマスターブランチに合わせて最新の状態に保ち、マージ中の労力を軽減するより効率的な方法を探しています。

140 version-control  git  github  versioning  branching 

私の組織はSVNからGitへの移行を検討しています。移動に対する1つの議論は次のとおりです。 バージョン管理はどのように行いますか？ NetBeansプラットフォームに基づいたSDKディストリビューションがあります。SVNリビジョンは単純な番号であるため、それらを使用してプラグインとSDKビルドのバージョン番号を拡張できます。Gitに移行するとき、これをどのように処理しますか？ 可能な解決策： Hudsonのビルド番号を使用する（問題：Hudsonを確認して、実際のGitバージョンと関連付ける必要があります） 夜間および安定のためにバージョンを手動でアップグレードする（問題：学習曲線、ヒューマンエラー） 他の誰かが同様の問題に遭遇してそれを解決した場合、私たちはどのように聞いてみたいです。

131 version-control  git  svn  builds  versioning 

異なるバージョンの命名規則は異なるプロジェクトに適していますか？何を使用し、その理由は？ 個人的には、16進数のビルド番号（11BCFなど）を好みます。これは非常に定期的に増やす必要があります。そして、顧客向けにシンプルな3桁のバージョン番号、つまり1.1.3。 1.2.3 (11BCF) <- Build number, should correspond with a revision in source control ^ ^ ^ | | | | | +--- Minor bugs, spelling mistakes, etc. | +----- Minor features, major bug fixes, etc. +------- Major version, UX changes, file format changes, etc.

107 project-management  development-process  naming  versioning 

Java 1.2はJava 2とも呼ばれます。「Java 1.x」と「Java x」（「Java 1.6」と「Java 6」など）は同じバージョンのJavaを指しますか？ もしそうなら、なぜこの二重性が必要なのでしょうか？

58 java  history  versioning  product-names 

ビルド番号について考えると、新しいナイトリービルドが作成されるたびに、新しいビルド番号が生成され、そのビルドに割り当てられます。したがって、7.0バージョンのアプリケーションでは、ナイトリービルドは7.0.1、7.0.2などになります。そうですか？それでは、ビルド番号の後のREVISIONの使用は何ですか？または、毎晩のビルド後に改訂部分が増分されますか？私はここで少し混乱しています...私たちは、各ナイトリービルドを参照してくださいBUILD？ 形式はここに記載されています：AssemblyVersion-MSDN

55 builds  versioning 

ニーズの異なる複数のクライアントがあります。ソフトウェアはある程度モジュール化されていますが、すべてのモジュールのビジネスロジックをあちこちで調整する必要があることはほぼ確実です。モジュールごとにクライアントを個別の（物理）モジュールに分割することを正当化するには、おそらく変更が小さすぎるため、ビルドの問題、リンクの混乱を恐れます。しかし、これらの変更は大きすぎて、構成ファイルのスイッチで構成するには多すぎます。これは、展開中に問題を引き起こし、特にティンカータイプの管理者では多くのサポートトラブルを引き起こす可能性があるためです。 ビルドシステムに、クライアントごとに1つずつ、複数のビルドを作成させて、問題の単一の物理モジュールの特殊バージョンに変更が含まれるようにします。だから私はいくつか質問があります： ビルドシステムに複数のビルドを作成させることをお勧めしますか？ソース管理、特にsvnにさまざまなカスタマイズを保存するにはどうすればよいですか？

46 versioning  continuous-integration 

ソフトウェア開発者は通常、日付をバージョン番号として使用しませんが、YYYYMMDD形式（またはそのバリエーション）は十分に堅実に見えます。そのスキームに何か問題はありますか？または、限定された「タイプ」のソフトウェアのみに適用されますか（社内制作など）。

43 versioning 

重複の可能性： どの「バージョン命名規則」を使用していますか？ リリース直前またはリリース直後にメジャー/マイナー/パッチのバージョン番号を変更しますか？ 例：1.0.0を世界にリリースしたばかりです（huzzah！）。しかし、待って、あまり祝福しないでください。1.1.0は6週間で公開されます！したがって、バグを修正して新しいビルドを実行します。そのビルドとは何ですか？1.1.0.0または1.0.0.xxxy（xxxyは1.0.0のビルド番号を増分したものです）？ 1.1.0に入るには、100の機能とバグがある可能性があることに注意してください。そのため、1.1.0に近いところがないため、1.0.0.xxxyと呼ぶのが良いかもしれません。しかし一方で、別の開発者が2.0.0で作業している可能性があります。その場合、ビルドはそれぞれ1.0.0.xxxyと1.0.0.xxxzではなく、1.1.0.0と2.0.0.0という名前を付けた方がよいかもしれません。

40 versioning 

最近、Webアプリケーションのバージョン管理について同僚と話し合いました。 私はあなたがそれを全く必要とは思わない、そしてあなたがあなたの最新リリースがライブであることを確認するために健全性チェックが欲しいだけなら、私はおそらく日付（YYMMDD）で十分だと思う。 私は基地を離れていますか？ポイントが足りませんか？Webアプリケーションのバージョン番号を使用する必要がありますか

35 web-applications  versioning 

提案されたビルドシステム（Gradle / Artifactory / Jenkins / Chef）をシニアアーキテクトの1人に説明していましたが、彼は私に同意しませんでしたが、実際に計量するのに十分な経験はありませんでした。 このプロジェクトは、他のチームが再利用するアーティファクトとしてJavaライブラリ（JAR）を構築します。バージョン管理には、次のセマンティックアプローチを使用します。 <major>.<minor>.<patch> どこにpatchバグ/緊急フィックスを示し、minor下位互換性リリースを示しており、majorいずれかのAPIの大規模なリファクタリングおよび/または互換性のない変更を示します。 ここでの配信に関しては、私が望むものです。開発者がコードをコミットします。これにより、QA / TEST環境へのビルドがトリガーされます。一部のテストは実行されます（一部は自動化され、一部は手動）。すべてのテストに合格すると、プロダクションビルドがJARを社内リポジトリに公開します。この時点までに、JARは適切にバージョン管理される必要があり、build.numberCIツールによって自動的に生成および提供されるものを使用して、パッチ番号として機能させることを考えていました。 したがって、バージョン管理は実際には次のようになります。 <major>.<minor>.<build.number> ここでも、build.numberCIツールによって提供される場所。 アーキテクトはこれを却下し、CIビルド番号の使用はセマンティックバージョニングの「乱用」であると述べました。 私の質問は次のとおりです。これは正しいですか？もしそうでなければ、なぜですか？

35 continuous-integration  versioning  builds  continuous-delivery  semantic-versioning 

プログラマがCVSよりもSVNを好む理由の1つは、前者がアトミックコミットを許可していることです。これは何を意味するのでしょうか ？

34 svn  versioning  cvs 

私は学校でプログラミングを学ばなかったし、（プロの）開発者として働いていないので、基本的なことの多くははっきりしていません。この質問では、そのうちの1つを明確にしようとします。 今度は、私は問題を抱えていると仮定しましょう#1、#2そして#3バージョンの強化/修正されるように設定されている私の問題トラッカーで1.0.0、最後の（安定）バージョンであること0.9.0。 いつバージョンを増やすべき1.0.0ですか？a）上記の問題の1つのみがクローズされた場合、またはb）バージョンに関連するすべての問題1.0がクローズされた場合 それを行う正しい方法はどれですか？そして、正しい方法で、私は業界で現在使用されているものを意味します。

23 versioning  semantic-versioning 

などの製品バージョンは、v1.0.0.100ソフトウェアの固有の製品リリースを表すだけでなく、その製品の機能セットと修正プログラムの段階を識別するのに役立ちます。現在、製品の最終パッケージ/ビルド/バイナリバージョンを維持するための2つの方法があります。 バージョン管理。ファイルはどこかにバージョン番号を保存します。Continuous Integration（CI）ビルドサーバーには、このチェックインバージョン番号を使用して必要なソフトウェアのすべての領域（バイナリ、インストーラーパッケージ、ヘルプページ、ドキュメントなど）に適用するソフトウェアをビルドするスクリプトがあります。 環境および/またはビルドパラメータ。これらはバージョン管理外で維持されます（つまり、スナップショット/タグ/ブランチに関連付けられていません）。ビルドスクリプトは、同じ方法で番号を配布および使用しますが、値の取得方法が異なります（ソースツリーに対する相対位置をスクリプトに知らせるのではなく、ビルドスクリプトに提供されます）。 最初のアプローチの問題は、メインラインのブランチ間でマージが複雑になる可能性があることです。同じソフトウェアの2つの並行リリースを引き続き維持する場合、最後のマージ以降に両方のバージョンが変更されている場合、2つのメインライン間のマージ時に競合を解決します。 2番目のアプローチの問題は、調整です。1年前のリリースに戻ると、タグ情報のみに依存してリリース番号を識別します。 どちらの場合も、CIビルドの前に知られていないバージョン番号の特定の側面があるかもしれません。たとえば、CIビルドは、実際には自動化されたビルド番号である4番目のコンポーネント（たとえば、ブランチ上の140番目のビルド）にプログラムで配置できます。VCSのリビジョン番号でもあります。 ソフトウェアのバージョン番号を把握する最善の方法は何ですか？VCSで「既知の」部品を常に維持する必要がありますか？もしそうなら、メインラインのブランチ間の競合は問題ですか？ 現在、CIビルドプラン（Atlassian Bamboo）で指定および維持されているパラメーターを介してバージョン番号を維持しています。masterブランチにマージする前に、CIビルドの開始前にバージョン番号が適切に設定されていることを注意する必要があります。Gitflowのワークフローに関しては、ソース管理でバージョン番号が追跡されていればrelease、リリースの準備でブランチを作成するときに、バージョン番号が適切に設定されることを保証できると思います。QAは、このブランチで最終的な統合/スモーク/回帰テストを実行し、サインオフ時に、masterリリースへのコミットメントを示すマージが行われます。

22 version-control  continuous-integration  versioning  release-management  continuous-delivery 

インターフェイスがあるとしましょうIFoo： public interface IFoo { void Bar(string s); int Quux(object o); } APIのバージョン2では、Glargこのインターフェイスにメソッドを追加する必要があります。既存のAPIユーザーを破壊せず、後方互換性を維持せずに、どのように行いますか？これは主に.NETを対象としていますが、他のフレームワークと言語にも適用できます。

22 versioning  interfaces 

一般的に、製品ライフサイクル中に複数のリリースがあり、以前の製品のサポートが必要な長期プロジェクトの場合、製品バージョンとコードベースの分岐を処理する最良の方法は何ですか？ より具体的な意味では、適切な分散バージョン管理（例：git）があり、チームの規模は小規模から大規模であり、開発者は一度に複数のプロジェクトに取り組んでいると想定します。直面している主要な問題は、その時点で存在していた古いバージョンをサポートする契約上の義務があることです。つまり、新しい開発では古いコードにパッチを適用できません（Microsoft Office製品がその例です。所有している機能年）。 その結果、各主要製品には複数の依存関係があり、それぞれのバージョンは年間リリース間で変更される可能性があるため、現在の製品のバージョン管理は複雑です。同様に、各製品には独自のリポジトリがありますが、ほとんどの作業はメインソーストランクではなく、その年の製品リリースのブランチで行われ、製品がサポートされるように製品がリリースされるときに新しいブランチが作成されます。これは、バージョン管理を使用するときに考えられるように、製品のコードベースを取得することは単純な問題ではないことを意味します。

21 version-control  versioning  branching  product-management