0

プロジェクトのバージョンを維持する効果的な方法は何ですか?

私はプロジェクトから始めましたが、それをプロフェッショナルに見せたいと思っています。プロジェクトのバージョンを 1.0 などにしたいのですが、それを維持する方法やどこから始めればよいかわかりません。小数点の前または小数点の後にバージョンをインクリメントするための基準はありますか、私はそのメジャーまたはマイナーな変更をどこかで読んだと思います。

また、コードに加えた変更に応じて、プロジェクトのバージョンで自動的に動作する既存のソフトウェアはありますか?

注: Code::Blocks を使用します

4

2 に答える 2

1


バージョン管理に関する多くの優れた情報については、これを 参照してください。使用している開発プラットフォームについては言及していませんが、それらのほとんどは自動インクリメントのバージョン番号をサポートしていますが、これはまったく新しいバージョンではなく、異なるビルドを示すためにのみ有効です。

于 2012-08-06T19:51:07.090 に答える
1

バージョン管理の基本を解説した記事はこちらソースコード管理

私がしているのは、4 つのフィールドのバージョン番号を持つことです。これは次のもので構成されています。

  • メジャー バージョン番号 (めったに変更されず、機能が大幅に変更された場合のみ)
  • マイナー バージョン番号 (機能が大幅に変更されると変更されることがあります)
  • 問題番号 (機能のマイナーな変更で変わります)
  • ビルドを行うたびに増加するビルド番号

この番号付け方式の目的は、現場で問題が発生した場合に、現場で問題が発生している特定のビルドでリポジトリ内のどのバージョンのソース コードが使用されたかを判断できるようにすることです。また、ファイル、データベース、機器など、どのようなテスト環境をセットアップする必要があるかを知ることもできます。

問題番号は、データベース スキーマに小さな影響を与える可能性のある機能の変更、新しいパラメーターの追加、顧客に要求された新しい機能の変更を行っている場合に変化する傾向があります。マイナー バージョン番号は、新しい機能または顧客の変更が重要な場合に変更される傾向があります。

メジャー番号は、古いメジャー バージョンから新しいメジャー バージョンへの移行が重要なアップグレード作業であることを意味する、本当に衝撃的な何かがある場合にのみ変更される傾向があります。変更されたケースは、Windows CE から Windows XP に移行したときで、オペレーティング システムの変更により、そのためにいくつかのソースの変更が必要になりました。同時に、極東アジア言語の UNICODE サポートも開始しました。

主なことは、完全なバージョン番号を確認したときに、そこにある主要な機能をすぐに知り、バージョンが主にサポートしているものとサポートしていないものを知ることができる方法を提供することです.

特定のフィールドがインクリメントされると、次のフィールドが 1 にリセットされます。したがって、Rel 2.2.1 から Rel 2.3.0 に移行する場合、最初のフィールドは同じままで、2 番目のフィールドは増分され、3 番目のフィールドはゼロに設定され、4 番目のフィールド (ビルド番号) は最初のビルドの 1 から始まります。 . 次に、Rel 2.3.0 のビルドがあると、4 番目のフィールド (ビルド番号) がインクリメントされます。

そして、ビルドを行うたびに、そのビルドのビルド製品 (インストーラー) をサーバーに保存し、ビルドに加えられた変更を説明するそのビルドのビルド ノートを保持します。また、そのビルドのソース コードを簡単に見つけられるように、リポジトリ (Subversion) にブランチを作成します。

于 2012-08-06T20:10:00.230 に答える