あいざわです

こんな感じではいかがでしょうか

---
 PATCHLEVEL BugFixのみ
 - 原則Bugfixのみ
 - これまで動いていたRubyプログラムが変更なしで動作する
 - ただし非公開APIに依存しているものは動かなくなるかも

 TEENY 機能追加したとき
 - 新しいクラスやメソッドの追加、大きな改善
 - 原則としてRubyで書かれたプログラムが変更なしで動作することを目指す
 - Cで書かれた拡張ライブラリが動かなくなることがある

 MINOR 大きな機能追加や変更、またはTEENYが9になった時の次
 - これまで動いていたRubyプログラムのParseが可能
 - 既存のRubyで書かれたプログラムがそのままでは期待どおりに動作しないことがある
 - その他、とても大きな機能追加があった場合
 # TEENYを上げるかMINORを上げるかは上記の基準をかんがみてリリースマネジャーが決定する

 MAJOR まつもとさんがあげると決心したとき以外上げない

** 例
- MVMが入った!→ TEENY
- GCが改善された!→ TEENY
- 公開APIが追加された → TEENY
- 公開APIが変更された、削除された→ MINOR
- 小数点を含む数値リテラルがRationalになった!→ MINOR
- Classboxが入った! → MINOR
- 標準添付ライブラリが整理された → MINOR

2011年10月20日12:24 NARUSE, Yui <naruse / airemix.jp>:
> 2011年10月20日3:31 Urabe Shyouhei <shyouhei / ruby-lang.org>:
>> たとえば2.0の次のバージョン番号はどうしますか?
>>
>> 厳格な運用を求めているわけではありませんので、2.1を出すと
>> 言っておいて出てみたら3.0だったとかでも全然構いませんが、
>> しかし方針を共有しておかないと2.0の後は一挙にカオスになっ
>> てしまうでしょう。現在の1.8.8のように。
>
> 比較的近い未来だと、2.0.0 の次をどうするかと、
> MVM が 2.0.0 に入らないとして、入った時どうなるのか、とか。
>
>> 将来のことは分かりませんというのは将来のことは考えても無
>> 駄ってのとは違うと信じています。逆で、将来のことは考えて
>> おかないといけない上に、予想通りにはいかないことも受け入
>> れないといけない。
>
> 卜部さんと同意見です。
> 加えて、バージョン番号は実は soname や lib/ruby 下のファイル名などに影響したり、
> 今どのくらいの非互換をつっこんでいいのかにも影響するので。
>
> しかし、ふと忘れてたんですが、major はあと 7 回しか上げられないので、
> もっとケチらないとダメですね。
>
> --
> NARUSE, Yui  <naruse / airemix.jp>
>
>