Feature #7252: version number of 2.0 release

• Status: Closed
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -

[usa (Usaku NAKAMURA)]

2月にリリースされるモノのバージョン番号はどうなる予定でしょうか?

例えばredmineでは「対象バージョン」に「2.0.0」とか書いてあるので、
2.0.0になるのかと思われがちですが、バージョン番号付けルールは
[ruby-dev:15923] にあるように、

1.9.0からは末尾0が開発版、1以降が安定版

とされており、以降変更されていない、と理解しています。

よって、ポイントは、

(1) 2月に出すのは安定版ですか? それとも1.9.0-Xの時のようなお試し版ですか?
(2) 安定版を出す場合、バージョン番号付けルールを変える? 変えない?

かと思います。

どういう予定でしょうか?

[kosaki (Motohiro KOSAKI)]

2.0.1 だとキャッチーさが薄れるのでお誕生日イベントの盛り上がり的には 2.0.0 or 2.0 のほうがいいなあ（ぼそっ

[mame (Yusuke Endoh)]

• Assignee changed from mame (Yusuke Endoh) to matz (Yukihiro Matsumoto)
• Priority changed from Normal to 7

usa (Usaku NAKAMURA) wrote:

よって、ポイントは、

(1) 2月に出すのは安定版ですか? それとも1.9.0-Xの時のようなお試し版ですか?
(2) 安定版を出す場合、バージョン番号付けルールを変える? 変えない?

かと思います。

予定は考えていませんでした。そろそろ引き締めないと。ありがとうございます。

提案ですが、(2) で、1.8 の時代に戻しませんか？
つまり 2.0 はすべて安定版、2.1 はすべて開発版。2 月にリリースするのは 2.0.0 。

今晩あたり実装予定 feature の告知の意味で preview1 をリリースしたいと画策して
いますので、まつもとさんが反対であれば至急返事を頂けると嬉しいです。
返事がなければ、2.0.0-preview1 という名前で出させてもらおうと思っています。

--
Yusuke Endoh [e-mail]

[matz (Yukihiro Matsumoto)]

まつもと ゆきひろです

1.8の頃のルールに戻すかどうかはまだ迷っているのですが、インパクトの観点から2/24にリリースするものは2.0.0にしたいです。

[naruse (Yui NARUSE)]

旧来の開発版/開発版とかもういらないんじゃないですかね。
trunkが開発版、リリースされたら安定版、で。

1.9/1.8 の時みたいに dev/stable の2系統持つという案もあり得るとは思いますが、
releaseブランチのメンテだけでも手一杯なのにstable ブランチの維持はちょっと出来る気があんまり……。
というので、正確には stable ブランチの復活に反対という意見かも。

まとめると、わたしは以下の通りにするのがよいと思います。（基本的に1.9.1以降の習慣の追認）

• trunkとリリースブランチがある。
• trunkにあるものが「開発版」。(ruby -v で X.X.Xdev とでる)
• trunkからリリースされたものが従来の用語での「安定版」。
• リリースされると、リリースブランチが作られ、適宜パッチリリースが行われる。
• 3.0とか将来のリリースで、1.9.0のような不安定なリリースが行われることは否定しない
• 実験的な仕様で遊びたい場合はgitでブランチ切ってください。trunkに入ったら多少のバグは頑張って直す

[shyouhei (Shyouhei Urabe)]

naruse (Yui NARUSE) wrote:

旧来の開発版/開発版とかもういらないんじゃないですかね。
trunkが開発版、リリースされたら安定版、で。

その行為が開発を促進するか停滞させるかは意見の分かれるところでしょう。

1.8がなくて1.9だけしかなかったらYARVは怖くて突っ込めなかったと思いますよ。

[ayumin (Ayumu AIZAWA)]

あいざわです

いちマーケターの意見としては、2/24には"2.0.0-p0" またはもっとシンプルに "2.0" で出すべきかなと思います。
その後の取扱を考えると"2.0.0-p0" を基本としてメッセージングとしては "2.0" を露出させていくのがよいかと。

ちなみにHerokuでは 2/28にwazaというテクニカルイベントを予定しており、2.0のリリースに合わせてHeroku
の環境下ですぐに ruby2.0を試してもらえるように社内調整を進めています。

On 2012/11/01, at 11:08, kosaki (Motohiro KOSAKI) [e-mail] wrote:

Issue #7252 has been updated by kosaki (Motohiro KOSAKI).

2.0.1 だとキャッチーさが薄れるのでお誕生日イベントの盛り上がり的には 2.0.0 or 2.0 のほうがいいなあ（ぼそっ

Feature #7252: version number of 2.0 release
https://bugs.ruby-lang.org/issues/7252#change-32132

Author: usa (Usaku NAKAMURA)
Status: Assigned
Priority: Normal
Assignee: mame (Yusuke Endoh)
Category: Project
Target version: 2.0.0

2月にリリースされるモノのバージョン番号はどうなる予定でしょうか?

例えばredmineでは「対象バージョン」に「2.0.0」とか書いてあるので、
2.0.0になるのかと思われがちですが、バージョン番号付けルールは
[ruby-dev:15923] にあるように、

1.9.0からは末尾0が開発版、1以降が安定版

とされており、以降変更されていない、と理解しています。

よって、ポイントは、

(1) 2月に出すのは安定版ですか? それとも1.9.0-Xの時のようなお試し版ですか?
(2) 安定版を出す場合、バージョン番号付けルールを変える? 変えない?

かと思います。

どういう予定でしょうか?

--
http://bugs.ruby-lang.org/

[kosaki (Motohiro KOSAKI)]

旧来の開発版/開発版とかもういらないんじゃないですかね。
trunkが開発版、リリースされたら安定版、で。

その行為が開発を促進するか停滞させるかは意見の分かれるところでしょう。

1.8がなくて1.9だけしかなかったらYARVは怖くて突っ込めなかったと思いますよ。

2.x は全部安定版にしてしまって、開発版が欲しくなるぐらいの重量級の機能が入ったら
3.0にバージョンアップしたて、またバージョンルールを定義しなおしたらいいのでは。
どうせこんなルール数年おきに変わっているのだし、あんまり深く議論しても意味ないかなあと思います。

YARV級の機能がはいったらみたいな「たられば」を言い出したら議論が発散することうけあいなので
あんまりシリアスにbikeshedを続けたくないなあ・・・・・

[ayumin (Ayumu AIZAWA)]

あいざわです

基本的に成瀬さんの意見に賛成で、2.0.x系統は頑張って互換性を保つように頑
張ってメンテをするということでいいと思います。

なにかしら非互換な変更が入りそうならその時になってからそれを2.1.xの中に
収めるか3.0にするか考えればいいのではないでしょうか。

個人的には3.0は相当将来の夢のリリースであっていて欲しいとおもっています。

[mame (Yusuke Endoh)]

• Priority changed from 7 to Normal

matz (Yukihiro Matsumoto) wrote:

まつもと ゆきひろです

1.8の頃のルールに戻すかどうかはまだ迷っているのですが、インパクトの観点から2/24にリリースするものは2.0.0にしたいです。

お返事ありがとうございます！では、"2.0.0" は確定としましょう。

ルールやブランチの切り方は、おいおい考えましょう。

--
Yusuke Endoh [e-mail]

[shyouhei (Shyouhei Urabe)]

On 11/01/2012 02:33 AM, KOSAKI Motohiro wrote:

旧来の開発版/開発版とかもういらないんじゃないですかね。
trunkが開発版、リリースされたら安定版、で。

その行為が開発を促進するか停滞させるかは意見の分かれるところでしょう。

1.8がなくて1.9だけしかなかったらYARVは怖くて突っ込めなかったと思いますよ。

2.x は全部安定版にしてしまって、開発版が欲しくなるぐらいの重量級の機能が入ったら
3.0にバージョンアップしたて、またバージョンルールを定義しなおしたらいいのでは。
どうせこんなルール数年おきに変わっているのだし、あんまり深く議論しても意味ないかなあと思います。

YARV級の機能がはいったらみたいな「たられば」を言い出したら議論が発散することうけあいなので
あんまりシリアスにbikeshedを続けたくないなあ・・・・・

この機能入れるとブランチ切らなきゃいけないから面倒だし入れるの止めようか、ってなるのを危惧しています。

具体的にはMVMなんですけど。あれやるとバイナリ互換から何から壊れるので。

[naruse (Yui NARUSE)]

2012年11月1日 23:50 Urabe Shyouhei [e-mail]:

On 11/01/2012 02:33 AM, KOSAKI Motohiro wrote:

旧来の開発版/開発版とかもういらないんじゃないですかね。
trunkが開発版、リリースされたら安定版、で。

その行為が開発を促進するか停滞させるかは意見の分かれるところでしょう。

1.8がなくて1.9だけしかなかったらYARVは怖くて突っ込めなかったと思いますよ。

2.x は全部安定版にしてしまって、開発版が欲しくなるぐらいの重量級の機能が入ったら
3.0にバージョンアップしたて、またバージョンルールを定義しなおしたらいいのでは。
どうせこんなルール数年おきに変わっているのだし、あんまり深く議論しても意味ないかなあと思います。

YARV級の機能がはいったらみたいな「たられば」を言い出したら議論が発散することうけあいなので
あんまりシリアスにbikeshedを続けたくないなあ・・・・・

この機能入れるとブランチ切らなきゃいけないから面倒だし入れるの止めようか、ってなるのを危惧しています。

具体的にはMVMなんですけど。あれやるとバイナリ互換から何から壊れるので。

今ってバイナリ互換性はバージョンアップごとに壊れるって言う見解なので、
そこは問題ないんじゃないですかね。

というか、ソース互換性が壊れていようが、2年以内に安定しそうならtrunkに
つっこんじゃえばいいし、つっこんで2年経って安定しなかったらその時改めて
マージ直前か前のリリースブランチから安定版ブランチを切って、backport祭りをすればよいかと。
（ちなみに、YARVマージの2年後は 1.9.1）

--
NARUSE, Yui [e-mail]

[mame (Yusuke Endoh)]

まつもとさん

またバージョン番号関連の話ですが、ABI の方針と名前はどうしましょう。
たたき台として以下を提案します。

• 方針: 少なくとも 2.0.x のうちは ABI は原則壊さない
• 名前: 2.0ABI

名前は適当ですが、1.9 の時の混乱 (Ruby 1.9.2 なのに ABI は 1.9.1 の
ままでややこしい) を踏まえて、同じ轍を踏まない名前にしたいですね。

[ruby-core:48984] で Vít Ondruch (Fedora のメンテナでしたっけ) が
早く決まれば嬉しいとか言ってます。

他の方もご意見ください。

--
Yusuke Endoh [e-mail]

[ayumin (Ayumu AIZAWA)]

あいざわです

[ruby-dev:44604] でも議論されていましたが、ABI互換性はTEENYバージョンの変更
であっても常に壊れる（可能性がある）という認識でいればいいと個人的には思います。

なので、以下を提案します。

• 方針: 少なくとも ruby 2.0.x のうちはパッチリリースを除いてABI互換は保証しない
  　（ABI互換が壊れるよな変更を入れる必要がある場合はパッチリリースではなく
  　　TEENYのバージョン番号を上げるリリースをおこなう）

• バージョン番号: rubyのバージョン番号（パッチの番号を除く）と同じ
  　例：ruby2.0.0-pxxx のABIバージョン -> ruby2.0.0
  　　　ruby2.0.1-pxxx のABIバージョン -> ruby2.0.1

---

Ayumu Aizawa

[naruse (Yui NARUSE)]

ayumin (Ayumu AIZAWA) wrote:

[ruby-dev:44604] でも議論されていましたが、ABI互換性はTEENYバージョンの変更
であっても常に壊れる（可能性がある）という認識でいればいいと個人的には思います。

なので、以下を提案します。

• 方針: 少なくとも ruby 2.0.x のうちはパッチリリースを除いてABI互換は保証しない
  　（ABI互換が壊れるよな変更を入れる必要がある場合はパッチリリースではなく
  　　TEENYのバージョン番号を上げるリリースをおこなう）

• バージョン番号: rubyのバージョン番号（パッチの番号を除く）と同じ
  　例：ruby2.0.0-pxxx のABIバージョン -> ruby2.0.0
  　　　ruby2.0.1-pxxx のABIバージョン -> ruby2.0.1

あいざわさんの仰るとおり、既に結論が出ていると思います。
付け加えるなら、毎回ABIバージョンを変えると言っても、不必要なABI互換性の破壊はない方がいいよね、くらい。

[mame (Yusuke Endoh)]

あれ、そういう結論が出てたんでしたっけ。すみません、把握できてませんでした。参照があれば教えてください。
方針には賛成です。Vit にも伝えた方がいいですね。

• バージョン番号: rubyのバージョン番号（パッチの番号を除く）と同じ
  　例：ruby2.0.0-pxxx のABIバージョン -> ruby2.0.0
  　　　ruby2.0.1-pxxx のABIバージョン -> ruby2.0.1

付け加えるなら、毎回ABIバージョンを変えると言っても、不必要なABI互換性の破壊はない方がいいよね、くらい。

こっちはいまいちよくわかってないんですが、Ruby 2.0.1 なのにインストールされるパスが 2.0.0 になるのは無用な混乱を招く、とかいう話なんですが、そこは大丈夫？

--
Yusuke Endoh [e-mail]

[naruse (Yui NARUSE)]

mame (Yusuke Endoh) wrote:

あれ、そういう結論が出てたんでしたっけ。すみません、把握できてませんでした。参照があれば教えてください。
方針には賛成です。Vit にも伝えた方がいいですね。

[ruby-dev:44610] で Yusuke Endoh ってひとが提案して、[ruby-dev:44674] で matz が承認してます。

• バージョン番号: rubyのバージョン番号（パッチの番号を除く）と同じ
  　例：ruby2.0.0-pxxx のABIバージョン -> ruby2.0.0
  　　　ruby2.0.1-pxxx のABIバージョン -> ruby2.0.1

付け加えるなら、毎回ABIバージョンを変えると言っても、不必要なABI互換性の破壊はない方がいいよね、くらい。

こっちはいまいちよくわかってないんですが、Ruby 2.0.1 なのにインストールされるパスが 2.0.0 になるのは無用な混乱を招く、とかいう話なんですが、そこは大丈夫？

インストールパスは ABI バージョンから生成されているので、インストールされるパスは 2.0.1 の下になります。

[ayumin (Ayumu AIZAWA)]

• Assignee changed from matz (Yukihiro Matsumoto) to mame (Yusuke Endoh)

少なくとも 2.0.0 を出すにあたって上記の方針で問題なければチケットをクローズしてください。

[mame (Yusuke Endoh)]

• Assignee changed from mame (Yusuke Endoh) to matz (Yukihiro Matsumoto)
• Target version changed from 2.0.0 to 2.6

ああ、忘れてました。提案したことも matz から承認されたことも忘れていた上に、このチケットまで忘れるとは我ながら惚れ惚れする忘却力。あいすみません。Vit への連絡もありがとうございます (あれだけでいいかな) 。

でまあ、2.0.0 と ABI については確定でいいと思うのですが、2.0.1 以降どうすんのか？という点は未定だと思うので (matz の「1.8の頃のルールに戻すかどうかはまだ迷っているのですが」のあたり) 、一応 next minor として残しておきましょうか。

--
Yusuke Endoh [e-mail]

[shugo (Shugo Maeda)]

別のチケットにしたり、英語で議論すべきなのかもしれませんが、まずは遠藤さんの考えを確認させてください。

mame (Yusuke Endoh) wrote:

ああ、忘れてました。提案したことも matz から承認されたことも忘れていた上に、このチケットまで忘れるとは我ながら惚れ惚れする忘却力。あいすみません。Vit への連絡もありがとうございます (あれだけでいいかな) 。

でまあ、2.0.0 と ABI については確定でいいと思うのですが、2.0.1 以降どうすんのか？という点は未定だと思うので (matz の「1.8の頃のルールに戻すかどうかはまだ迷っているのですが」のあたり) 、一応 next minor として残しておきましょうか。

2.0.0は安定版になるような話の流れなのかなと思っていますが、誰がメンテナンスするかというのは
議論されていましたっけ。
ruby_2_0_0ブランチを誰が見るかということですが、遠藤さんは2.0.0のリリース後のメンテナンス
についてはどのようにお考えでしょうか。

すでに意見を表明されていたらすみません。

[mame (Yusuke Endoh)]

shugo (Shugo Maeda) wrote:

2.0.0は安定版になるような話の流れなのかなと思っていますが、誰がメンテナンスするかというのは
議論されていましたっけ。
ruby_2_0_0ブランチを誰が見るかということですが、遠藤さんは2.0.0のリリース後のメンテナンス
についてはどのようにお考えでしょうか。

そうそう。リマインドしてくれてありがとうございます。

メンテナンスは誰か他の人にお願いしたいと思っています。
傲慢にリリースすることには興味あるのですが、根気と正確さが要求されるメンテナンスには自信ないので。
当然、メンテナンスのポリシーは遠藤ではなくメンテナが決めることです。

誰にメンテナになってもらうかはまつもとさんの判断次第ですが、個人的には nagachika さんを推薦します。
ruby-trunk-changes をやってくれてる nagachika さんの根気と正確さは誰もが知るところだと思います。

ということで、nagachika さん、まつもとさん、どうでしょうか。

(なお、誤解ないように付け足しますが、trunk の全コミットを読んでることの根気と正確さを評価しているだけで、全自動的にバックポートしてくれることと期待しているわけではないです)

[shugo (Shugo Maeda)]

前田です。

2013年1月11日 22:00 mame (Yusuke Endoh) [e-mail]:

メンテナンスは誰か他の人にお願いしたいと思っています。
傲慢にリリースすることには興味あるのですが、根気と正確さが要求されるメンテナンスには自信ないので。
当然、メンテナンスのポリシーは遠藤ではなくメンテナが決めることです。

なるほど、了解です。
ではリリースまでにメンテナを決めないといけないですね。

誰にメンテナになってもらうかはまつもとさんの判断次第ですが、個人的には nagachika さんを推薦します。
ruby-trunk-changes をやってくれてる nagachika さんの根気と正確さは誰もが知るところだと思います。

ということで、nagachika さん、まつもとさん、どうでしょうか。

nagachikaさんがもしやってくださるならありがたいですが、まずは御本人の意向をお聞きしたい
と思います。
このあたりのやり取りは日本語でいいのかなという気もしますが、メンテナを決めるところまでは
日本語でやって、メンテナンスポリシーなどの話はruby-coreに移動するのがスムーズですかね。

あと、Rubyアソシエーションで現在1.9.3のメンテナンスをTOUAさんに委託していますが、 2.0.0
についてはまだ枯れていないことや、予算の問題を考えると委託するのは難しいかなと個人的に
思っています。
ただ、緊急の脆弱性対応などを部分的に委託することは検討できるかもしれません。

--
Shugo Maeda

[kosaki (Motohiro KOSAKI)]

あと、Rubyアソシエーションで現在1.9.3のメンテナンスをTOUAさんに委託していますが、 2.0.0
についてはまだ枯れていないことや、予算の問題を考えると委託するのは難しいかなと個人的に
思っています。
ただ、緊急の脆弱性対応などを部分的に委託することは検討できるかもしれません。

ええと、メンテナ複数人は二人のオフィスが同じとかなにかないとコミュニケーションコストが増えた分がペイできないような気がします。あと二人いて一人だけお金が出るというのも感情的な問題が出るおそれがあるので、当事者からの希望が出るまではペンディングしていいんじゃないでしょうか

フルタイムの予算がおりるならそれにこしたことはないけど、それもここで

議論すべきではないよね

[shugo (Shugo Maeda)]

前田です。

2013年1月12日 2:58 KOSAKI Motohiro [e-mail]:

あと、Rubyアソシエーションで現在1.9.3のメンテナンスをTOUAさんに委託していますが、 2.0.0
についてはまだ枯れていないことや、予算の問題を考えると委託するのは難しいかなと個人的に
思っています。
ただ、緊急の脆弱性対応などを部分的に委託することは検討できるかもしれません。

ええと、メンテナ複数人は二人のオフィスが同じとかなにかないとコミュニケーションコストが増えた分がペイできないような気がします。あと二人いて一人だけお金が出るというのも感情的な問題が出るおそれがあるので、当事者からの希望が出るまではペンディングしていいんじゃないでしょうか

そうですね。
上記は、緊急の脆弱性対応が必要になった時に2.0.0のメンテナが対応できない場合に、
スポットで1.9.3のメンテナンス委託先に対応してもらうようなことなら、予算措置も含めて
検討できるかもしれないというくらいの意図でした。

メンテナをやりたいけど、本業で忙しい時に脆弱性が報告されるのが不安という人も

いるかと思いますので。

--
Shugo Maeda

[nagachika (Tomoyuki Chikanaga)]

近永です。

返信が遅くなりすみませんでした。
遠藤さん推薦ありがとうございます。

一応確認させて頂きますが 2.0.0 ブランチはリリースブランチで、
stable ブランチは廃止という前提ですよね?

またわたしの理解ではブランチメンテナの仕事は主に

• Backport すべき変更の判断と実際のコミット
• Backport チケットの対応
• patchlevel release 作業
  といったところだと思っていますがだいたいあってるでしょうか。

上記に大きく勘違いがなければ、引き受けてもかまいません。
もちろん他にやりたい熱意のある人がいればお譲りしますけど。

不安要素は脆弱性対策で緊急にリリースが必要になった時に充分リソースが
割けない状態にあったらどうしようということでしたけど、前田さんが
おっしゃってるような措置も考えられるのであれば多少は安心です。

2013年1月11日 22:00 mame (Yusuke Endoh) [e-mail]:

Issue #7252 has been updated by mame (Yusuke Endoh).

shugo (Shugo Maeda) wrote:

2.0.0は安定版になるような話の流れなのかなと思っていますが、誰がメンテナンスするかというのは
議論されていましたっけ。
ruby_2_0_0ブランチを誰が見るかということですが、遠藤さんは2.0.0のリリース後のメンテナンス
についてはどのようにお考えでしょうか。

そうそう。リマインドしてくれてありがとうございます。

メンテナンスは誰か他の人にお願いしたいと思っています。
傲慢にリリースすることには興味あるのですが、根気と正確さが要求されるメンテナンスには自信ないので。
当然、メンテナンスのポリシーは遠藤ではなくメンテナが決めることです。

誰にメンテナになってもらうかはまつもとさんの判断次第ですが、個人的には nagachika さんを推薦します。
ruby-trunk-changes をやってくれてる nagachika さんの根気と正確さは誰もが知るところだと思います。

ということで、nagachika さん、まつもとさん、どうでしょうか。

(なお、誤解ないように付け足しますが、trunk
の全コミットを読んでることの根気と正確さを評価しているだけで、全自動的にバックポートしてくれることと期待しているわけではないです)

Feature #7252: version number of 2.0 release
https://bugs.ruby-lang.org/issues/7252#change-35354

Author: usa (Usaku NAKAMURA)
Status: Assigned
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: Project
Target version: next minor

2月にリリースされるモノのバージョン番号はどうなる予定でしょうか?

例えばredmineでは「対象バージョン」に「2.0.0」とか書いてあるので、
2.0.0になるのかと思われがちですが、バージョン番号付けルールは
[ruby-dev:15923] にあるように、

1.9.0からは末尾0が開発版、1以降が安定版

とされており、以降変更されていない、と理解しています。

よって、ポイントは、

(1) 2月に出すのは安定版ですか? それとも1.9.0-Xの時のようなお試し版ですか?
(2) 安定版を出す場合、バージョン番号付けルールを変える? 変えない?

かと思います。

どういう予定でしょうか?

--
http://bugs.ruby-lang.org/

[naruse (Yui NARUSE)]

• Target version deleted (2.6)

[hsbt (Hiroshi SHIBATA)]

• Status changed from Assigned to Closed

2.0.0 リリース時のディスカッションなので閉じておきます。