「ソフトウェアのバージョンアップ」が以前と変わった理由とは？

2025年9月に「Java 25」がリリースされました。Javaは現在、6カ月ごとに“フィーチャーリリース”と呼ばれるバージョンアップが行われており、その前のバージョンである「Java 24」は2025年3月に、そこから半年前の2024年9月には「Java 23」がリリースされています。

しかし、以前のJavaのバージョンアップはこのように定期的なものではありませんでした。例えば「Java 7」が登場したのは2011年7月、その次の「Java 8」が登場したのは2年8カ月後の2014年3月でした。さらに次の「Java 9」が登場したのは3年6カ月後の2017年9月でした。

過去のJavaにおいて新バージョンが登場するまで長い時間がかかり、しかもその期間がばらついていた理由は、バージョンアップするのは「新しい機能が追加されたときや大きな機能変化が行われたとき」というルールに基づいていたからです。このようなバージョンアップを「フィーチャー（機能）ベースのバージョンアップ」と呼びます。

一方、最近のJavaのように「6カ月ごとに自動的にバージョンアップを行う」ことを「タイムベースのバージョンアップ」と呼びます。

かつては、ほとんどのソフトウェアがフィーチャーベースのバージョンアップを行っていました。代表的なのはマイクロソフトのWindowsでしょう。「Windows 3.1」が1992年に発表され、その3年後の1995年に登場したのが「Windows 95」でした。さらに3年後の1998年に「Windows 98」、2000年に「Windows ME」、そして2001年に「Windows XP」と、数年ごとに登場した新しいWindowsはいずれも大幅な機能の追加やユーザーインターフェイスの刷新が行われていました。

しかし、2021年に「Windows 11」が登場してからは、こうした大型のバージョンアップが行われていません。その代わり、ほぼ毎年10月頃に登場する「24H2」や「25H2」などと呼ばれる定期的なアップデートが提供されるようになっています。

Windowsにおいても、フィーチャーベースのバージョンアップからタイムベースのバージョンアップへと、事実上、バージョンアップのポリシーが変更されているのです。

なぜJavaやWindowsのバージョンアップはフィーチャーベースからタイムベースへと切り替わったのでしょうか。

フィーチャーベースのバージョンアップはユーザー視点から見て2つの欠点がありました。1つ目は、次にいつバージョンアップがあるのか、時期の予想がつきにくいという点です。2つ目は、バージョンアップごとに大きな機能追加や変更が発生するため、アプリケーションの互換性チェックなどの手間が大きいという点です。

ユーザー側からすると、フィーチャーベースのバージョンアップは対応するのにコストや手間がかかるのに、いつそれが必要になるかを予想しにくく計画を立てるのが難しいといった困難さがあったのです。

例えば、あるソフトウェアの新バージョンが登場して、その対応のために予算と工数を見積もってやっと翌年にバージョンアップを開始したら、早くもその翌年には次のバージョンが登場することになって、こんなことならもう少し待ってまとめてのバージョンアップをすればよかったとなったり、あるいは新バージョン対応のためのコストや工数がしばらく確保できないので、次のバージョンアップまで見送ろうとしても、その次がいつになるのかわからないので見送る判断もできないとなったりするわけです。

そこで、ユーザーに対してバージョンアップの予見性を少しでも高め、計画しやすくするために登場したのがタイムベースのバージョンアップです。

タイムベースではJavaのように「半年ごとのバージョンアップ」など、いつバージョンアップが行われるのかがあらかじめ決められています。そして、そのタイミングで完成した新しい機能をはじめ機能の変更や改善がそのバージョンで取り入れられていきます。

またほとんどの場合、タイムベースのバージョンアップでは数年以上のサポートが約束される「長期サポート（Long Term Support）版」（LTS版）も設定されています。LTS版ではバグフィックスや安定性など品質を重視したリリースが行われており、LTS版以外のバージョンアップでは新機能の追加などが積極的に行われる傾向にあります。

Javaなら2年ごと、.NETも2年ごとにLTS版がリリースされるようになっており、このLTS版を選択して利用することで、特定のバージョンを長期で安定的に使いたいという企業などの要求に応えられるようになっています。

そしてタイムベースのバージョンアップでは、一般的にフィーチャーベースのバージョンアップよりも短い期間でバージョンアップが行われることもあり、バージョンアップごとの変化が緩やかで、ユーザーによるバージョンアップ対応の作業が容易とも言えます。

タイムベースのバージョンアップでは、ユーザーがいつどのバージョンに移行するかを主体的に計画しやすく取り組みやすくなります。その結果、スムーズな新バージョンへの移行が促進されることになるわけです。

現在では前述のJavaやWindows、.NETだけでなく、多くのソフトウェアがタイムベースのバージョンアップを採用しています。

例えば「Python」は毎年10月に新バージョンをリリース。「Node.js」は毎年4月と10月の6カ月ごとにメジャーアップデートが行われます。「PHP」は12カ月ごと、「Ruby」も12カ月ごとにバージョンアップが行われています。

Webブラウザでも「Google Chrome」「Microsoft Edge」「Mozilla Firefox」のいずれもが4週間ごとに新バージョンを登場させていることをご存じの方も多いでしょう。

このように言語やOS、Webブラウザといった多くのユーザーを抱えているソフトウェアでは、タイムベースのバージョンアップが採用されてきています。ソフトウェアが企業にとっても社会にとっても、基盤としての重要性を増していくなかで、ユーザーが主体的に計画を立てて取り組みやすいタイムベースのバージョンアップは今後ますます広がっていくことでしょう。