デスクトップアプリケーションのセマンティックバージョニング
ライブラリまたはAPIを開発すれば セマンティックバージョニング の推奨事項に簡単に従うことができますが、開発した製品がWebサイトやデスクトップアプリケーションの場合はどうなりますか？
その場合、いつmajorコンポーネントをインクリメントしますか？
完全なUI再設計の場合は？または、他の何か？
考え？
セマンティックバージョニングは、ほとんどのデスクトップアプリケーションの番号付けと競合しているようです。 「製品のバージョン管理」をマーケティング部門に引き渡すことでこれを解決し、すべてのコンポーネントに対して完全に個別の（ただし、私たちにとっては論理的な）バージョンを維持しています。特定の製品バージョンは、互換性のあるコンポーネントの定義されたコレクションになります。コンポーネント間のセマンティックバージョニングの維持ははるかに簡単です。
私はデスクトップまたはWebアプリケーションにセマンティックバージョニングを採用したので、私たちの作業ではX.Y.Zを使用しています。
- リリースにバグ修正、依存関係の更新、または一部のアプリケーション内部の変更のみが含まれている場合、Zは増加しているため、ユーザーに新機能は導入されていません。
- リリースにUIのマイナーな変更が含まれている場合、またはユーザーに影響を与えるいくつかの新機能や機能の再設計/機能の更新が導入されている場合、Yは増加します。
- リリースにメジャーUI /機能の更新が含まれている場合、Xは増加します。たとえば、次のとおりです。新しいインターフェイスの設計/レイアウト。
- 新しいプロジェクトはバージョン0.1で始まり、マイナーバージョンは開発に伴って増加しています。
- プロジェクトにバージョン1.0のすべての計画された機能が含まれている場合、バージョンを1.0に変更する必要があります。
古い投稿ですが、解決策を探していて、偶然に遭遇しました このBrett Uglowの記事 （ permalink ）これは、バージョン管理アプリケーションについて今まで読んだ中で最高のものですエンドユーザー、特にデスクトップアプリケーションに直接配信されます。
記事からの抜粋：
...
installer-user
Installer-userは、アプリケーションをインストールする必要がある人です。彼らにとって、アプリケーションの「パブリックAPI」はインストール要件です。しかし、インストーラーユーザーは誰ですか？
Twitterモバイルアプリとデスクトップアプリの場合、インストーラーは（通常）エンドユーザーです。インストール要件は、オペレーティングシステムとインターネット接続の最低限必要なバージョンです。
Twitter Webアプリケーションの場合、インストーラーはDevOps（またはOperations）チームの誰かです。これらの要件に基づいて適切なインフラストラクチャをプロビジョニングする必要があるため、インストール要件に深く関心があります。
提案
インストーラーユーザーに対するアプリケーションのインストール要件の重要性を考えると、インストーラーユーザーをこのAPIのコンシューマーとして使用し、インストール要件をパブリックAPIとして使用して、エンドユーザーアプリケーションのバージョン管理に使用することをお勧めします。
実際には、次の値を増やします。
互換性のないAPI変更を行った場合の主要なバージョン（例：インストーラー-ユーザーはインフラストラクチャ（電話/タブレット/ PC /ウェブサーバー/ファイアウォール設定/その他）を何らかの方法で変更する必要があります）、
下位互換性のある方法で機能を追加する場合のマイナーバージョン（たとえば、既にプロビジョニングされているAPIに追加のデータを渡すか、インストール要件に影響しないエンドユーザー機能を追加する）、および
下位互換性のあるバグ修正を行うときのパッチバージョン（たとえば、インストール要件に影響を与えないエンドユーザーのバグの修正）。
インストーラーユーザーをエンドユーザーアプリケーションのコンシューマーとして扱い、インストール要件をパブリックAPIとして扱うことで、semverは意味があり、エンドユーザーアプリケーションの通信メカニズムとして価値があると思います。