web-dev-qa-db-ja.com

アプリケーションのバージョン管理戦略は何ですか？

SOコミュニティの最高のアプリケーションバージョン管理戦略に関する意見を募集しています。

私の質問：

  1. アプリケーションのバージョン番号をどのように追跡しますか？そのバージョンの各数字/文字が何を表すのか、正式な定義がありますか？

  2. アプリケーションのバージョン内の異なる数字/文字列は、アプリにとってどのような意味がありますか？

  3. アプリで自動更新システム（Sparkleなど）を使用していますか？

  4. アプリのベータテスターまたはプレリリーステスター用の個別の更新手順はありますか？

versioningstrategy
22
Andrei

  • アプリケーションのバージョン番号をどのように追跡しますか？そのバージョンの各数字/文字が何を表すのか、正式な定義がありますか？

  • アプリケーションのバージョン内の異なる数字/文字列は、アプリにとってどのような意味がありますか？

私は以下を使用します：

AppName_<Major>.<Minor>.<Patch/Upgrade>.<BuildNo>

メジャー-メジャーバージョンは、製品の明確なリリースです。機能に大きな変更があった場合に増加しました。

マイナー-新しい機能または主要なバグ修正のみが追加された場合、マイナーバージョンが増分されます。

アップグレード/パッチ-アップグレードとは、製品を新しいバージョンの製品に置き換えることを指します。指定されたメジャーリリースでアップグレードが提供された場合にのみ増分されます。パッチバージョンは0から始まり、バグが発生した場合にのみ増分されます解決されました。

ビルド番号-新しいビルドが作成されると、ビルド番号が増加します。

  • アプリで自動更新システム（たとえば、Sparkleなど）を使用していますか？

私たちは、夜間ビルドと呼ばれるアプリを夜間に自動的にビルドするビルドツールを使用します。これにより、ビルドが作成されるたびにビルド数が増加します。

  • アプリのベータテスターまたはプレリリーステスター用の個別の更新手順はありますか？

いいえ。テスターは毎朝BAT（Build Acceptance Test）と呼ばれる夜間ビルドでテストを行い、夜間ビルドを検証します。

16
Harry Joy

まず、「最善の」戦略については合意がないようです。私の経験は、現在のプロジェクトでしか共有できません。

  1. システムバージョンは、ビルドプロパティで手動で定義されます。これは、チームが新しいリリースに同意したときに発生します。追加のバージョン管理として、CIビルドによって自動的に生成されるビルド番号を使用します

  2. Ubuntuの命名規則は緩やかに従いますYY.MM.version.patch_buildNumber Major.Minorバージョン管理が顧客の期待を台無しにすることがわかったので、;）

  3. アプリケーションは管理者がロールアウトする必要があるため、自動更新はありません

  4. テストリリースはGAリリースよりも頻繁ですが、それだけで十分です。

12
kostja

私は多くのバージョンのシステムをテストしましたが、今はこれにかなり満足しています。

[メジャー]。[マイナー]。[リビジョン]

  • メジャーは手動で設定され、メジャーな改善を含むバージョンを参照します
  • マイナーも手動で設定され、マイナーな改善と修正を含むアップグレード/メンテナンスリリースを参照します
  • リビジョンは自動的に生成され、リポジトリ内の正確なリビジョンを参照します。

最後のバージョンでは、バージョン管理を非常に柔軟に行うことができます。複数のクライアントに複数のバージョンを出荷し、リポジトリから特定のバージョンを取得してトランクにマージすることで、デバッグと修正を簡単に行うことができます。

ビルド、パッケージング、公開は完全に自動化されています。唯一の手動のアクションは、最後のパッケージをFTPで本番サーバーに移動するときです。私たちは、それを制御し続けて、生産でがらくたを配信しないようにします。それは、早期導入者がリリースノートを読んでから、バージョンをダウンロードして使用することを決定できる準備段階に進みます。特定のバグに直面した顧客は、これらのバージョンのいずれかを使用することにより、修正バージョンを非常に速く入手できます。

10
user2567

私のオープンソースライブラリには Semantic Versioning を使用しており、他のライブラリでも同様に機能するのではるかに簡単です。バージョンの変更の意味を理解するための共通の基盤を提供します。ライブラリはまだベータ版ですか？バグ修正のみのリリースですか？重大なAPIの変更はありますか？

これは基本的に、ほとんどのオープンソースプロジェクトですでに使用されているバージョン管理のベストプラクティスを体系化したものです。

10
Rein Henrichs

重要なのは、リリースに一意の番号を付けて、簡単に識別できるようにすることです。その数がどのように分解されるかは、実際には重要ではありません。私が気にするバージョンは、major.minor.customerID.buildnumberです。ビルド番号は、ビルドスクリプトから自動生成されます。

0
Andy Wiesendanger