高速なメジャーバージョンバンピングは、デザインの悪さの証拠ですか？

私は数ヶ月前にジュニアプログラマーとして仕事を始めました。私たちが取り組んでいるシステムは、2年ほど実稼働しています。私はシステムと設計の物inいには関与していませんでした。

私が気づいたことの1つは、システムのメジャーバージョンがすでに11.YZであるということです。他のシステムやライブラリでの作業経験から、製品がメジャーバージョンをそれほど速く動かしたのを見たことはありません。1.XYで長年使用されている製品がありますが、まだ機能とバグ修正を受けています。

セマンティックバージョニングが適切に使用されていると仮定すると、これは、システムがほぼ4か月ごとに重大な重大な変更を行うため、設計が不十分であることを示していますか？

セマンティックバージョニングが適切に使用されていると仮定すると、これは、システムがほぼ4か月ごとに重大な重大な変更を行うため、設計が不十分であることを示していますか？

必ずしも。

コメントで、これは内部APIであると述べました。みんなのコードを壊すので、APIを壊すのは悪いことです。しかし、内部APIの場合、「誰も」は「あなた」であり、そのようなAPIの変更を自分で完全に調整できるので、通常はAPIの変更に伴う痛みははるかに少なくなります。

また、平均は非常に誤解を招く可能性があります。初期開発の最初の数日間に11の重大なAPIの変更があり、それ以来4年間安定していたのでしょうか。SemVerでは、メジャー番号が0の場合、メジャー番号を増やすことなく重大な変更を加えることができますが、強制することはありません。おそらく彼らは、プロトタイプ作成/探索段階でも、0日目からSemVerの使用を開始しましたか？

短い答え

番号

長い答え

「数字は単なる数字である場合がある」

現在のクレイジーな世界で「セマンティックバージョニング」、「合理性」、「論理」を忘れる

Chromeがバージョン番号をすぐに取得するのはなぜですか？

「バージョン」番号は、他の開発者が使用する方法を公開するメジャーリリースではなく、ブランチポイントのマイルストーンとして使用されます。そして、多くの新しい機能を集めて大きなイベントを作るというよりも、機能が準備されているか準備ができていない継続的な開発フローです。

セマンティックバージョニングを使用する場合、どの変更が「メジャー」と見なされ、どの変更が「マイナー」であるかを決定する必要があります。バージョン番号を上げるか、または上げないさまざまな理由があります。

下位互換性が約束されているシステムは、多少の難解なコーナーケースで下位互換性が破られているという理由だけで、ほとんどのアップデートでメジャーバージョン番号を上げる可能性があります。同じシステムが1.xyにほぼ無期限に固執する可能性があります。これは、下位システムとの互換性に多大な労力が費やされ、依存システムを壊さないようにするためです。バージョン番号付けの両方のアプローチは「保守的」と考えることができますが、根本的な問題の兆候ともなります。

また、メジャーバージョン番号を変更するのが理にかなっているリリーススケジュール（四半期ごとに更新されるCDを顧客に送信することを考えてください）があり、「バージョン3.4 / 10月16」の代わりに「バージョン11.0」とだけ言う場合もあります。最近では、ますます多くのソフトウェアが短い間隔でリリースされ、リリーススケジュールが特定のバージョン管理スキームに固執する理由が少なくなっています。これは、社内ITが1四半期に1日（通常は日曜日）のダウンタイムしか許可しない大きな倉庫システムで見ました。この日は展開日であり、毎回新しいメジャーバージョンでマークされます。

一部のプログラムには、ユーザーが両方を同時に更新する必要があるため、非常に重要な外部依存関係があります。Word 2010とWord 2013でのみ動作するWordアドオンがある場合、MS-Wordのメジャーバージョン番号と同期することをお勧めします。ここで、メジャー番号は非常に重要です。ユーザーの一部は、最新バージョンのWord（または依存している他のSAP、Dynamics、等）。

他の外部要因がバージョン番号を決定する場合があります。会計ソフトウェアをお持ちの場合、税法に対応する年次更新がある可能性があります（1月1日に施行される傾向があります）。そのようなシステムには、1年に1回だけメジャーバージョンが変更されます-それは更新スケジュールではなく、それが顧客にとって他の重要性のためです：2016年の税を行う場合、2016年の税法に更新されるプログラムを持っていることをお勧めします。

最終的に、バージョン番号は非常に多くの要因に依存します-多くの場合、1つのドメインに固有であるため、番号だけではコードベースの状態については何もわかりません。展開がいつ、なぜ、どのように行われるか、そしてそれがどれだけスムーズに行われるかを見るのは、はるかに優れたアプローチです。10.000の顧客にメジャーアップデートを展開して、電話を数回受けることができる場合は、おそらく大丈夫です。10人の顧客にマイナーパッチを展開し、そのために残業しなければならない場合、何かがおそらく間違っています。

バージョン番号の意味に関するコンセンサスは、実際はmajor.minor.revision.buildnumberです。

メジャーが急速に上昇した場合、開発者がこれらすべての新しいアイデアを持ち、本当に一生懸命働くことができます。

しかし、ビジネスの世界では、メジャーバージョン番号を増やす他の理由があるかもしれません。お気に入り

• 売り上げは落ちており、クライアント/ユーザーはアップグレードの前に次の大きなメジャーリリースを待っています。

• この契約では、クライアントにはマイナーアップデートの権利があります。ベンダーはそれらに課金できないため、メジャーな製品アップグレードとしてマイナーな改善が販売されます。

• 競合他社Xはもう少しゲームに参加しているので、メジャーバージョン番号はたまたまあなたのものよりも大きくなっています。これにより、遅れているように見え、「追いつく」必要があります。