--pgp-sign-Multipart_Sat_Aug_31_02:30:14_2013-1
Content-Type: text/plain; charset=ISO-2022-JP

At Fri, 30 Aug 2013 21:49:34 +0900,
I wrote:
> misc #8835: Introducing a semantic versioning scheme and branching policy
> https://bugs.ruby-lang.org/issues/8835

 DevelopersMeeting20130831Japanでのプレゼンのために、[ruby-core:56878]
[misc #8835] を日本語で補足します。

 直接的なきっかけは [ruby-list:49555] のスレッドです。元の問題自体は、
RubyGemsを直すべきだと思います。ただ、1.8, 1.9, 2.0と、バージョンの運用
状況が毎回なんとなしに変わってきており、PATCHLEVELまであるRUBY_VERSION
がAPI互換性については多くを示さず、RUBY_API_VERSIONが別途あるというのは
ちょっといただけない状況だと思いました。

 そこで、この提案は [MAJOR & MINOR, TEENY, PATCHLEVEL] がSemantic
Versioning (http://semver.org/)に沿うように再定義しようというものです。
Ruby自体をAPI互換性を考慮したバージョン体系にすることによって、1.9で導
入されたもののあまり有意義に運用されなかったRUBY_API_VERSIONと統一し、
両者の不一致から来る潜在的なユーザの混乱および互換性に関する懸念の解消
を図ります。

 開発陣におけるABI互換性についての意識は高まっており、試験的ながら
Ruby-CIにもABIチェックが入っているので、Semantic Versioningを運用してい
くことが現実的に可能だと思います。

 TEENYが9までしか使えないという縛りはありますが、MAJOR.MINOR.0のリリー
ス後に、APIを追加・拡張したリリースを9回も行う必要は薄く、いつでも追加・
拡張をやめてバグ修正のみのフェーズに移行できるので、枯渇を気にする必要
はないでしょう。

 機能追加を行った次のTEENYリリースを準備中に、もしセキュリティ等に関す
るクリティカルな修正が必要になった場合は、それ以外の修正も入った次の
TEENYリリース準備ブランチの安定を確認する必要はなく、現行のTEENYリリー
スブランチからすぐにPATCHLEVELリリースを行えます。つまり、PATCHLEVELは
主にセキュリティ修正レベルという意味づけになり、リリースする側の手間が
減ることはもちろん、安定性や互換性を重視するベンダーやユーザのニーズに
応えるものです。

 なお、1.8系列および1.9系列ではTEENYの違いでもABI/API非互換があったの
で各TEENYごとにそれぞれ保守を続ける必要が生じていましたが、このスキーム
では、新しいTEENYが出たら上位互換性を盾に1つ前のTEENYの保守をすぐに打ち
切れます。ただ、継続を望むベンダーがいれば、古いTEENYのブランチを保守し
てもらうのもありでしょう。(coreチームとしてのリリースは行わないでしょ
うが)

 ブランチの作成・運用手順についても記述しています。これはFreeBSDや
NetBSDに倣ったもので、特に独自な点はありません。

--
Akinori MUSHA / https://akinori.org/

--pgp-sign-Multipart_Sat_Aug_31_02:30:14_2013-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (FreeBSD)

iEYEABECAAYFAlIg1qYACgkQkgvvx5/Z4e4i8ACg2pBDEGtYvxCgdnzPX51zhJO0
M5MAniWr8+HCxhhAYTu4jFTRsCLmAWDj
=epjg
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Sat_Aug_31_02:30:14_2013-1--