[ruby-dev:47669] Re: [ruby-core:56878] [ruby-trunk - misc #8835][Open] Introducing a semantic versioning scheme and branching policy

At Fri, 30 Aug 2013 19:49:59 -0400,
KOSAKI Motohiro wrote:
> えっ。
> いまのパッチレベルリリースはほとんどのケースでシンボルの追加があると思いますが。

はい。意味を変えるという提案なので。仮に 2.0 系列に新しいスキームを適用
していたとすると、パッチレベルリリースは半年ちょっと経ちましたがまだ2回
だけなので現在 2.0.2 になっており、仮に年内にあと2回くらい機能追加を含
むリリースを出したとして 2.0.4、そこで 2.1.0 が出て、前方互換性を改善す
る機能追加や拡張を行いましょうというときにあと5回変身を残している感じで
す。十分ではないでしょうか。（後方非互換性については後述）

> あと、Rubyのクラスは「開いている」ので、どんなバグフィックスであってもあやしげなモンキーパッチャーさんはぎゃっというリスクはあるわけで、このルールだとパッチレベルだけですむケースがほぼ無くなるんじゃないかなあ。

パッチレベルだけで済まない変更を加えた上でのリリースの余地が9回あれば、
現在のリリースサイクルを見るに十分ではないかというのが主旨です。

> 開発陣におけるABI互換性についての意識は高まっているという認識にも懐疑的で、意識している人はしているししていない人は全然していないので、メンテナーの負荷を減らすにはコミッターの善意だけではだめでツールの助けがいるというのが
> ABI checker導入時のバックグラウンドモチベーションとしてありました。

そもそも現在API versionというのが実は何の役割も果たしていない（1.9でも
2.0でもTEENYすら上がっていないし後方互換性も保たれていない）状況ですが、
少なくとも追加や拡張があるので上げるべき、削除や変更があるのでバックポー
ト不可、という判断がツールの支援である程度デジタルにできるようになりま
した。

> 実際問題として1.9.3とかp0と最新では結構な非互換が検出されてます。
>
> というわけで、カウンタープロポーサルとして、TEENYを0固定にして、パッチレベルはsymbol削減方向の非互換はしないが、symbol追加の非互換はあり（rb_,
> ruby_ prefixの関数を自モジュールにつかう拡張が悪い）というRubyオレオレルールを継続することを提案します。

それだと、追加されたシンボルに依存したバイナリ物を配布するときにバージョ
ン番号でチェックできないのが困ります。ビルド時や実行時はextconf.rb や
respond_to? 等々でチェックもできますが、RubyGemsを含むパッケージシステ
ムがインストールの際にバージョン番号で比較するしかないというところにニー
ズがあります。

> ついでに、いまはRubyレベルの非互換について、一切ツール支援がない状況ですので、こちらについても対策に関する意見を広く募集したいところです。

そうですね。そこは課題として認識します。

> > 　機能追加を行った次のTEENYリリースを準備中に、もしセキュリティ等に関す
> > るクリティカルな修正が必要になった場合は、それ以外の修正も入った次の
> > TEENYリリース準備ブランチの安定を確認する必要はなく、現行のTEENYリリー
> > スブランチからすぐにPATCHLEVELリリースを行えます。つまり、PATCHLEVELは
> > 主にセキュリティ修正レベルという意味づけになり、リリースする側の手間が
> > 減ることはもちろん、安定性や互換性を重視するベンダーやユーザのニーズに
> > 応えるものです。
>
> モチベーションは理解できます。少なくともパッチレベルでの非互換はなくしたいですね。
>
> 実際の運用として、p0の後の最初の２つぐらいのパッチレベルリリースは非互換ありでも許されてきた経緯があり（どうせp0なんか使うやついないという判断により）、どのタイミングで非互換なしになるのかはメンテナーに任されていた部分が大だったと思います。

1.9.0 はプレビュー版、 1.9.1 はデベロッパー版みたいな感じでしたね。2.0
系列は、1.9での苦難のleapを果たした直後だけにうまく行きすぎているという
のはあります。

> これが、当初の２−３回のリリースはTEENYあげる。（Rubyコミュニティが99.9%のユーザが被害を受けないと考えるような）小さな非互換もありうる。それ以降はパッチレベルでsymbol
> 削除方向の非互換はなし。とかだったら分かりやすいし、ツール支援もしやすいので賛成しやすいですね。

新しいスキームでも TEENY=0 くらいはプレビュー扱いで TEENY=1 で非互換も
あるよ、というのもいいかもしれません。少なくともどこからメンテナンス
フェーズか、非互換はあるか、という指針を内外に示すことが大事。

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