Ruby 2.0 release plan

44604 "NARUSE, Yui" <naruse airemix.jp> (2011-10-18 15:27:41 +0900) Ruby 2.0 release plan

Sasada-san already posted some messages for ver 2.0 but there's no
discussion about release plan. Here's a draft release plan.

= next version

2.0. No 1.9.4 unless someone volunteers.
# I understand that Sasada-san dropped his proposal on 1.9.4.

= versioning scheme

Change as follows;

MAJOR: bumps for breaking ABI backward compatibility
MINOR: bumps for releases which are backward compatible
TEENY: always 0
PATCHLEVEL: for the release branch, we bump the patch level by 1 for each patch (each commit).

= 2.0 release schedule

December 24, 2012: preview 1 (feature freeze)
February 24, 2013: release (20th birthday of Ruby)

See also [ruby-dev:27275]

= release policy

Meet the deadline no matter what happens.
Do not add features that won't make it in time for the deadline, and revert if the feature is holding back the release.

No commits except for fixing regression bugs after code freeze.

= introduce a release engineering team

Considering the great efforts of Endoh-san and Kosaki-san for 1.9.2 and 1.9.3 respectively, I think that a release is too much work for a single person.

Beside this, when we allow backporting by anyone who find bugs, the policy "Do not backport without permission from the release manager" becomes a meaningless limitation. I propose to change the policy to "(...) without permission from the release engineering team".

= summary

Matz, please bump version.h to 2.0.0.

-- 
NARUSE, Yui  <naruse / airemix.jp>
Refine translation / View logs (3)
ささださんが既にいくつか 2.0 関連のメールを投げていらっしゃいますが、
ど真ん中リリースプランについてのが無いと思うので、
とりあえず日本語でリリースプランをまとめました。

= 次のバージョン

2.0 とする。
1.9.4 は特に手を挙げるものが現れない限りリリースしない。
(ささださんは撤回したと理解しています)

= バージョニング規則

以下の通り変更する。

MAJOR: (ABI の) 後方互換性を切るときに上げる
MINOR: 後方互換性を保ったリリースの際に上げる
TEENY: 常に 0
PATCHLEVEL: リリースブランチについて、patch 1 つにつき 1 つ加算

= 2.0 リリーススケジュール

2012 年 12 月 24 日 preview 1 (feature freeze)
2013 年  2 月 24 日 release (Ruby 20歳)

see also [ruby-dev:27275]

= リリースエンジニアリングの方針

何があろうとこの日付に出す。
間に合わない機能は入れないし、足を引っ張ったら revert する。

* code freeze 後の修正は regression のみとする

= リリースエンジニアリングチームの導入

1.9.2 での mame さんの活躍や、1.9.3 での kosaki さんの活躍を鑑みるに、
要するに一人じゃリリースは困難だと思うのです。

一方でその場で気づいた人が backport という方針だと、今度は「フリーズ後は
release manager の許可無く backport しないこと」の縛りが形骸化するので、
これを「release engineering team の許可無く」に変えよう、というわけです。

= まとめ

まつもとさん、version.h を 2.0.0 に変えてください

-- 
NARUSE, Yui  <naruse / airemix.jp>

44609 SASADA Koichi <ko1 atdot.net> (2011-10-18 16:38:53 +0900) Re: Ruby 2.0 release plan

 Sasada here.

(2011/10/18 16:15), Yukihiro Matsumoto wrote:
> |Matz, please bump version.h to 2.0.0.
> 
> I'll change and commit tomorrow morning. Those who want make a branch should
> do it before that. Well, you can probably create it whenever it becomes
> necessary, but ...

  Why not wait for 1.9.3?

-- 
// SASADA Koichi at atdot dot net

Refine translation
 ささだです.

(2011/10/18 16:15), Yukihiro Matsumoto wrote:
> |まつもとさん、version.h を 2.0.0 に変えてください
> 
> 明日の午前中に変更してコミットします。ブランチを作りたい人は
> それまでに。まあ、必要になってから作ればいいのだろうけど。

 1.9.3 は待たないのでしょうか.

-- 
// SASADA Koichi at atdot dot net

44610 Yusuke Endoh <mame tsg.ne.jp> (2011-10-18 17:41:47 +0900) Re: Ruby 2.0 release plan

Hi,

2011-10-18 15:27 NARUSE, Yui <naruse / airemix.jp>:
> = versioning scheme
> 
> Change as follows;
> 
> MAJOR: bumps for breaking ABI backward compatibility
> MINOR: bumps for releases which are backward compatible
> TEENY: always 0
> PATCHLEVEL: for release branch, bumps per patch (commit).

Shall we let go of the binary compatibility? Even we break ABI's backward compatibility, rebuilding would be enough as long as we keep C source level compatibility.

As a practical matter, now almost all libraries are gems. I think that rebuilding all gems (NaHi: I don't know he means 'all' or just 'default gems') while 'make install' would be sufficient. I'll ask Eric Hodel whether it is really doable.

So I propose:

MAJOR: bumps for breaking C/Ruby source level backward compatibility

-- 
Yusuke Endoh <mame / tsg.ne.jp>

Refine translation
遠藤です。

2011年10月18日15:27 NARUSE, Yui <naruse / airemix.jp>:
> = バージョニング規則
>
> 以下の通り変更する。
>
> MAJOR: (ABI の) 後方互換性を切るときに上げる
> MINOR: 後方互換性を保ったリリースの際に上げる
> TEENY: 常に 0
> PATCHLEVEL: リリースブランチについて、patch 1 つにつき 1 つ加算


もう 2.0 では binary compatiblity にこだわるのをやめません?
ABI の後方互換性が崩れても C ソースレベルで互換性があれば、
リビルドすれば済むわけなので、リビルドしてください、という
ことで。

実際問題としては、今やほとんどのライブラリは gem なので、
アップグレードの make install 時に拡張ライブラリの gem を
リビルドするよう gem コマンドを呼び出せば、ユーザはとくに
意識しなくて済むと思います。
本当にできるかどうかはちょっと Eric Hodel と相談してみます。


というわけで、

MAJOR: C・Ruby ソースレベルの後方互換性を切るときに上げる

がいいと思います。

-- 
Yusuke Endoh <mame / tsg.ne.jp>

44611 Ayumu Aizawa <ayumu.aizawa gmail.com> (2011-10-18 17:43:26 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
あいざわです。

後方互換性を保ちながら、大きめの新機能が追加になるときにMINORをあげて、
そうでない場合はTEENYをあげるだけにするとかはいかがでしょうか。

どっちにするかは(最終的には)リリースエンジニアリングチームの判断になるのかな。

44605 "Shota Fukumori (sora_h)" <sorah tubusu.net> (2011-10-18 15:49:39 +0900) Re: Ruby 2.0 release plan

sora_h here.

On 10/18/11 3:27 PM, NARUSE, Yui wrote:
> = versioning scheme
(snip)
> TEENY: always 0
> PATCHLEVEL: for the release branch, we bump the patch level by 1 for each patch (each commit).

I thought that maybe we could make the TEENY version number correspond to the patchlevel. What do you think?

In other words, if we have patch 290, then the version becomes something like 2.0.290.

Ugly?

> Beside this, when we allow backporting by anyone who find bugs, the 
> policy "Do not backport without permission from the release manager" 
> becomes a meaningless limitation. I propose to change the policy to 
> "(...) without permission from the release engineering team".
.
I agree completely. However, I think that we should make it clear what exactly the release engineering team's tasks are before introducing it.
-- 
Shota Fukumori a.k.a. sora_h - http://sorah.jp/

Refine translation
sora_h です.

On 10/18/11 3:27 PM, NARUSE, Yui wrote:
> = バージョニング規則
(snip)
> TEENY: 常に 0
> PATCHLEVEL: リリースブランチについて、patch 1 つにつき 1 つ加算

PATCHLEVEL を TEENY してもいいんじゃないとか思うんですが,どうでしょう.

要するに patch 290 だったら 2.0.290 みたいな感じ.

ダサい?

> 一方でその場で気づいた人が backport という方針だと、今度は「フリーズ後は
> release manager の許可無く backport しないこと」の縛りが形骸化するので、
> これを「release engineering team の許可無く」に変えよう、というわけです。

ちょう賛成です.release engineering team の仕事もはっきりさせてから導入
するのが良いと思います.

-- 
Shota Fukumori a.k.a. sora_h - http://sorah.jp/

44606 Urabe Shyouhei <shyouhei ruby-lang.org> (2011-10-18 16:14:20 +0900) Re: Ruby 2.0 release plan

On 10/18/2011 03:49 PM, Shota Fukumori (sora_h) wrote:
> sora_h です.
> 
> On 10/18/11 3:27 PM, NARUSE, Yui wrote:
>> = バージョニング規則
> (snip)
>> TEENY: 常に 0
>> PATCHLEVEL: リリースブランチについて、patch 1 つにつき 1 つ加算
> 
> PATCHLEVEL を TEENY してもいいんじゃないとか思うんですが,どうでしょう.
> 
> 要するに patch 290 だったら 2.0.290 みたいな感じ.
> 
> ダサい?

That won't work. We have a restriction on Ruby's version numbers that says that they must consist of a single digit. If we want to remove this restriction then it seems that we must establish a new version class that includes Comparable.
 
Refine translation
On 10/18/2011 03:49 PM, Shota Fukumori (sora_h) wrote:
> sora_h です.
> 
> On 10/18/11 3:27 PM, NARUSE, Yui wrote:
>> = バージョニング規則
> (snip)
>> TEENY: 常に 0
>> PATCHLEVEL: リリースブランチについて、patch 1 つにつき 1 つ加算
> 
> PATCHLEVEL を TEENY してもいいんじゃないとか思うんですが,どうでしょう.
> 
> 要するに patch 290 だったら 2.0.290 みたいな感じ.
> 
> ダサい?

だめです。Rubyのバージョン番号には一桁でなければならないという制限があります。
それを撤廃するなら適切にComparableをincludeしたバージョンクラスを新設する必要があるはずです。

44607 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-18 16:15:56 +0900) Re: Ruby 2.0 release plan

Hi,

In message "Re: [ruby-dev:44604] Ruby 2.0 release plan"
    on Tue, 18 Oct 2011 15:27:41 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes:

|= versioning scheme
|
|Change as follows;
|
|MAJOR: bumps for breaking ABI backward compatibility
|MINOR: bumps for releases which are backward compatible
|TEENY: always 0
|PATCHLEVEL: for release branch, bumps per patch (commit).

I'm not much for rigidly defined rules because it tends to turn into "completionism".

|= 2.0 release schedule
|
|December 24, 2012: preview 1 (feature freeze)
|February 24, 2013: release (20th birthday of Ruby)

Agreed.

|= a team for release engineering
|
|Outstanding performance of Endoh-san and Kosaki-san for 1.9.2 and 1.9.3 indicates that a new release is a bit much for one person I think.
|
|Beside this, when we allow backporting by anyone who find bugs, the policy "Do not backport without permission from release manager" would become a dead letter. My proposal is to change the policy to "without permission from the release engineering team".

Agreed.

|= summary
|
|Matz, please bump version.h to 2.0.0.

I'll change and commit tomorrow morning. Those who want make a branch should do it before that. Well, you can probably create it whenever it becomes necessary, but ...
Refine translation / View logs (2)
まつもと ゆきひろです

In message "Re: [ruby-dev:44604] Ruby 2.0 release plan"
    on Tue, 18 Oct 2011 15:27:41 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes:

|= バージョニング規則
|
|以下の通り変更する。
|
|MAJOR: (ABI の) 後方互換性を切るときに上げる
|MINOR: 後方互換性を保ったリリースの際に上げる
|TEENY: 常に 0
|PATCHLEVEL: リリースブランチについて、patch 1 つにつき 1 つ加算

あんまりルールをきっちり決めるのは好きじゃない(完了主義にな
りがちだから)のですが。

|= 2.0 リリーススケジュール
|
|2012 年 12 月 24 日 preview 1 (feature freeze)
|2013 年  2 月 24 日 release (Ruby 20歳)

賛成します。

|= リリースエンジニアリングの方針
|
|何があろうとこの日付に出す。
|間に合わない機能は入れないし、足を引っ張ったら revert する。
|
|* code freeze 後の修正は regression のみとする
|
|= リリースエンジニアリングチームの導入
|
|1.9.2 での mame さんの活躍や、1.9.3 での kosaki さんの活躍を鑑みるに、
|要するに一人じゃリリースは困難だと思うのです。
|
|一方でその場で気づいた人が backport という方針だと、今度は「フリーズ後は
|release manager の許可無く backport しないこと」の縛りが形骸化するので、
|これを「release engineering team の許可無く」に変えよう、というわけです。

賛成します。

|= まとめ
|
|まつもとさん、version.h を 2.0.0 に変えてください

明日の午前中に変更してコミットします。ブランチを作りたい人は
それまでに。まあ、必要になってから作ればいいのだろうけど。

44608 "Shota Fukumori (sora_h)" <sorah tubusu.net> (2011-10-18 16:35:15 +0900) Re: Ruby 2.0 release plan

Of course -- I'd completely forgotten about RUBY_VERSION.

If we make TEENY always 0 it's fine to not show it, unless it would cause issues when comparing with older versions or something?

On 10/18/11 4:14 PM, Urabe Shyouhei wrote:
> That won't work. We have a restriction on Ruby's version numbers that says
> that they must consist of a single digit. If we want to remove this
> restriction then it seems that we must establish a new version class that
> includes Comparable.

-- 
Shota Fukumori a.k.a. sora_h - http://sorah.jp/
Refine translation / View logs (2)
RUBY_VERSION の存在をすっかり忘れていました.なるほど.

TEENY 常に 0 なら表示しなくても良いんじゃないかと思うんだけど,過去の
バージョンとの比較とかで問題になる?

On 10/18/11 4:14 PM, Urabe Shyouhei wrote:
> だめです。Rubyのバージョン番号には一桁でなければならないという制限があります。
> それを撤廃するなら適切にComparableをincludeしたバージョンクラスを新設する必要があるはずです。

-- 
Shota Fukumori a.k.a. sora_h - http://sorah.jp/

44612 Yusuke Endoh <mame tsg.ne.jp> (2011-10-18 17:43:35 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
遠藤です。

2011年10月18日15:27 NARUSE, Yui <naruse / airemix.jp>:
> = リリースエンジニアリングチームの導入
>
> 1.9.2 での mame さんの活躍や、1.9.3 での kosaki さんの活躍を鑑みるに、
> 要するに一人じゃリリースは困難だと思うのです。
>
> 一方でその場で気づいた人が backport という方針だと、今度は「フリーズ後は
> release manager の許可無く backport しないこと」の縛りが形骸化するので、
> これを「release engineering team の許可無く」に変えよう、というわけです。


話がおかしい気がするのですが、その「活躍」は backport 作業の
話ではない気がします。私はほとんど backport した覚えがないし。


ブランチ管理とかアナウンスとかチケット処理の事務作業、つまり
リリースエンジニアリングはチーム制でやればいいと思います。

でも、意思決定が大きく関わること、つまりリリースマネジメント
にチーム制は向いていないと思います。指揮系統があいまいになる
ので。


具体的には、「状況を見てスケジュールを見直す (バグの重大度と
修正期間を予想してリリース延期を決める)」とか「マイルストーン
ごとにアナウンス出す (or 誰かに出せと指示する)」とか。
大きな機能を取り入れるかどうかの議論のファシリテートと、決定
なんかも仕事だと思います。

backport の話でも、バグかどうか微妙なときに判断を下す人は必要
なんじゃないかと。

ただ、すでにスケジュールが決まっていて、本当に文字通り、
「何があろうとこの日付に出す」のだったら、リリースマネジメ
ントでやることはあまりなさそうではありますが。
この成瀬さんのメールでリリースマネジメント半分終わりというか。


現状の問題は、単に Yugui さんが忙しすぎるというだけだと思い
ます。そういう場合はリリースマネージャの権限ごと他人に渡す
べきだと思います。


まとめると、

  - リリースマネージャ制度自体は今まで通りでよい
  - リリースマネージャは事務作業でもっと他人を使うべき
  - 判断・指示すらできなくなったらリリースマネージャを
    辞めるべき

少しきつい言い方になってますが、今までの Yugui さんの功績を
否定するつもりはありません。
redmine とか定着させたのはとてもすばらしい。

-- 
Yusuke Endoh <mame / tsg.ne.jp>

44613 "NARUSE, Yui" <naruse airemix.jp> (2011-10-18 18:44:07 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
2011年10月18日17:41 Yusuke Endoh <mame / tsg.ne.jp>:
> 遠藤です。
>
> 2011年10月18日15:27 NARUSE, Yui <naruse / airemix.jp>:
>> = バージョニング規則
>>
>> 以下の通り変更する。
>>
>> MAJOR: (ABI の) 後方互換性を切るときに上げる
>> MINOR: 後方互換性を保ったリリースの際に上げる
>> TEENY: 常に 0
>> PATCHLEVEL: リリースブランチについて、patch 1 つにつき 1 つ加算
>
> もう 2.0 では binary compatiblity にこだわるのをやめません?
> ABI の後方互換性が崩れても C ソースレベルで互換性があれば、
> リビルドすれば済むわけなので、リビルドしてください、という
> ことで。

「こだわらない」とはどのような意味ですか。
「リビルドしてください」と言うには後方互換性が崩れたことを知る必要があるわけですが。

> 実際問題としては、今やほとんどのライブラリは gem なので、
> アップグレードの make install 時に拡張ライブラリの gem を
> リビルドするよう gem コマンドを呼び出せば、ユーザはとくに
> 意識しなくて済むと思います。
> 本当にできるかどうかはちょっと Eric Hodel と相談してみます。

Windows ではどうするのでしょう。

> MAJOR: C・Ruby ソースレベルの後方互換性を切るときに上げる
>
> がいいと思います。

MINOR では切らないんですかね。

-- 
NARUSE, Yui  <naruse / airemix.jp>

44614 "NARUSE, Yui" <naruse airemix.jp> (2011-10-18 18:45:58 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
2011年10月18日16:38 SASADA Koichi <ko1 / atdot.net>:
> (2011/10/18 16:15), Yukihiro Matsumoto wrote:
>> |まつもとさん、version.h を 2.0.0 に変えてください
>>
>> 明日の午前中に変更してコミットします。ブランチを作りたい人は
>> それまでに。まあ、必要になってから作ればいいのだろうけど。
>
>  1.9.3 は待たないのでしょうか.

もういいんじゃないですかね。
keyword arguments のような 2.0 の話題がコミット寸前まで言ってるわけですし。

-- 
NARUSE, Yui  <naruse / airemix.jp>

44615 "NARUSE, Yui" <naruse airemix.jp> (2011-10-18 18:58:14 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
2011年10月18日17:43 Ayumu Aizawa <ayumu.aizawa / gmail.com>:
> あいざわです。
>
> 後方互換性を保ちながら、大きめの新機能が追加になるときにMINORをあげて、
> そうでない場合はTEENYをあげるだけにするとかはいかがでしょうか。
>
> どっちにするかは(最終的には)リリースエンジニアリングチームの判断になるのかな。

現在の体制では 1年~2年おきになるのと、別にパッチリリースという仕組みがあるので、
TEENY だけを上げるようなリリースが行われることは考えづらいのと、
その判断をするのが面倒なのでいらないんじゃないですかね。
もっと頻度が上がったらまた必要になることもあるかもしれません。

-- 
NARUSE, Yui  <naruse / airemix.jp>

44616 Ayumu Aizawa <ayumu.aizawa gmail.com> (2011-10-18 19:24:34 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
あいざわです。

>> 後方互換性を保ちながら、大きめの新機能が追加になるときにMINORをあげて、
>> そうでない場合はTEENYをあげるだけにするとかはいかがでしょうか。
>>
>> どっちにするかは(最終的には)リリースエンジニアリングチームの判断になるのかな。
>
> 現在の体制では 1年~2年おきになるのと、別にパッチリリースという仕組みがあるので、
> TEENY だけを上げるようなリリースが行われることは考えづらいのと、
> その判断をするのが面倒なのでいらないんじゃないですかね。
> もっと頻度が上がったらまた必要になることもあるかもしれません。

あんまり強く主張する気はないんですが、その時々の変更インパクトによってMINORとTEENYを
使い分ける余地があった方がマーケティング的に(?)メッセージを出しやすいとかあるんじゃない
かと思ってます。

世間のみんなに是非使ってもらいたい新機能を入れたときは2.1.0とかで出してそうでもないときは
2.0.1にするとか。

44617 "NARUSE, Yui" <naruse airemix.jp> (2011-10-18 19:46:29 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
(2011/10/18 19:24), Ayumu Aizawa wrote:
> あんまり強く主張する気はないんですが、その時々の変更インパクトによってMINORとTEENYを
> 使い分ける余地があった方がマーケティング的に(?)メッセージを出しやすいとかあるんじゃない
> かと思ってます。
> 
> 世間のみんなに是非使ってもらいたい新機能を入れたときは2.1.0とかで出してそうでもないときは
> 2.0.1にするとか。

インパクトがある変更があるときは 3.0 にするというのがこれの趣旨なのですよ。

-- 
NARUSE, Yui  <naruse / airemix.jp>

44677 Yusuke Endoh <mame tsg.ne.jp> (2011-10-23 13:53:52 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
遠藤です。

2011年10月23日1:41 Yukihiro Matsumoto <matz / ruby-lang.org>:
> ABIの互換性を維持を保証しようとするとコストが高すぎると思いま
> す。ほんの些細な違いでもABI互換性は崩れちゃうわけで。という
> 意味で、TEENYだろうがABIは変化する(かもしれない)というルール
> で良いと思います。ディスクの節約とか気にする時代じゃないし。

そうですよね。
Eric Hodel も実装簡単そうって言ってくれてるし、その方針で
考えて行きましょう。

-- 
Yusuke Endoh <mame / tsg.ne.jp>

44618 "NARUSE, Yui" <naruse airemix.jp> (2011-10-18 19:47:32 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
(2011/10/18 16:15), Yukihiro Matsumoto wrote:
> In message "Re: [ruby-dev:44604] Ruby 2.0 release plan"
>     on Tue, 18 Oct 2011 15:27:41 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes:
> 
> |= バージョニング規則
> |
> |以下の通り変更する。
> |
> |MAJOR: (ABI の) 後方互換性を切るときに上げる
> |MINOR: 後方互換性を保ったリリースの際に上げる
> |TEENY: 常に 0
> |PATCHLEVEL: リリースブランチについて、patch 1 つにつき 1 つ加算
> 
> あんまりルールをきっちり決めるのは好きじゃない(完了主義にな
> りがちだから)のですが。

これは第一には「1.9 までの規則と違うよ!」って意味ですね。
前提として現在までの1年以上間を置くリリースを踏襲するってのがあるので、
そこが変わった場合はまた違った形になるかもしれません。

-- 
NARUSE, Yui  <naruse / airemix.jp>

44619 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-18 22:16:51 +0900) Re: Ruby 2.0 release plan

Hi, Matz.

In message "Re: [ruby-dev:44618] Re: Ruby 2.0 release plan"
    on Tue, 18 Oct 2011 19:47:32 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes:

|> |MAJOR: (ABI の) 後方互換性を切るときに上げる
|> |MINOR: 後方互換性を保ったリリースの際に上げる
|> |TEENY: 常に 0
|> |PATCHLEVEL: リリースブランチについて、patch 1 つにつき 1 つ加算
|> 
|> あんまりルールをきっちり決めるのは好きじゃない(完了主義にな
|> りがちだから)のですが。
|
|これは第一には「1.9 までの規則と違うよ!」って意味ですね。
|前提として現在までの1年以上間を置くリリースを踏襲するってのがあるので、
|そこが変わった場合はまた違った形になるかもしれません。

Version numbers are not the inportant matter. The number should be up when we think it should be up. Even if you need more rules, followings would be just enough:

 PATCHLEVEL only bug fixes
 TEENY when release changes not bug fixes
 MONOR next version of TEENY reaches 9 or the 'bigger' release than TEENY
 MAJOR what we think it should be MAJOR release.
Refine translation / View logs (2)
まつもと ゆきひろです

In message "Re: [ruby-dev:44618] Re: Ruby 2.0 release plan"
    on Tue, 18 Oct 2011 19:47:32 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes:

|> |MAJOR: (ABI の) 後方互換性を切るときに上げる
|> |MINOR: 後方互換性を保ったリリースの際に上げる
|> |TEENY: 常に 0
|> |PATCHLEVEL: リリースブランチについて、patch 1 つにつき 1 つ加算
|> 
|> あんまりルールをきっちり決めるのは好きじゃない(完了主義にな
|> りがちだから)のですが。
|
|これは第一には「1.9 までの規則と違うよ!」って意味ですね。
|前提として現在までの1年以上間を置くリリースを踏襲するってのがあるので、
|そこが変わった場合はまた違った形になるかもしれません。

バージョン番号なんて飾りなんで、上げたいと思ったときに上げる
のが良いのだと思います。そういう意味では以前のまま。あえてルー
ルを決めるとしたら、原則として、

 PATCHLEVEL バグフィックスのみ
 TEENY バグ以外の変更をリリースする時
 MONOR TEENYが9になった次、またはより大きな変更した時
 MAJOR なんか決心した時

くらいでいいような。

44620 Yusuke Endoh <mame tsg.ne.jp> (2011-10-18 23:03:42 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
遠藤です。

2011年10月18日18:44 NARUSE, Yui <naruse / airemix.jp>:
>> もう 2.0 では binary compatiblity にこだわるのをやめません?
>> ABI の後方互換性が崩れても C ソースレベルで互換性があれば、
>> リビルドすれば済むわけなので、リビルドしてください、という
>> ことで。
>
> 「こだわらない」とはどのような意味ですか。
> 「リビルドしてください」と言うには後方互換性が崩れたことを知る必要があるわけですが。

常に崩れている (可能性がある) ので、必ずリビルドしてください
ということです。


>> 実際問題としては、今やほとんどのライブラリは gem なので、
>> アップグレードの make install 時に拡張ライブラリの gem を
>> リビルドするよう gem コマンドを呼び出せば、ユーザはとくに
>> 意識しなくて済むと思います。
>> 本当にできるかどうかはちょっと Eric Hodel と相談してみます。
>
> Windows ではどうするのでしょう。

バイナリ gem かあ。
MINOR リリースごとに gem リリースしてください、かなあ。
警告出した上で古い gem を使えるようにしてもいいかもですが。
ffi 化を進めたくなる気持ちがわかりますね。


>> MAJOR: C・Ruby ソースレベルの後方互換性を切るときに上げる
>>
>> がいいと思います。
>
> MINOR では切らないんですかね。

切るんですかね?

-- 
Yusuke Endoh <mame / tsg.ne.jp>

44621 KOSAKI Motohiro <kosaki.motohiro gmail.com> (2011-10-18 23:16:18 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
>>> MAJOR: C・Ruby ソースレベルの後方互換性を切るときに上げる
>>>
>>> がいいと思います。
>>
>> MINOR では切らないんですかね。
>
> 切るんですかね?

いままでも、実害なさそうなABI非互換は色々と入っていたし、
セキュリティ問題とか出たらABI言ってられない状況も出てくるでしょう。

ABI100%互換を決めた瞬間に、セキュリティ問題が報告されてCインターフェースが変わるたびにメジャー番号があがることになって、ちょっと好ましくないかなあ。セキュリティ問題があったことなんて、あんまり大々的に宣伝するものでもないし

44641 Takahiro Kambe <taca back-street.net> (2011-10-20 14:44:14 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
In message <E1RGlHs-0005kO-MK / X220>
	on Thu, 20 Oct 2011 14:35:28 +0900,
	Yukihiro Matsumoto <matz / ruby-lang.org> wrote:
> In message "Re: [ruby-dev:44639] Re: Ruby 2.0 release plan"
>     on Thu, 20 Oct 2011 14:14:46 +0900, Nobuyoshi Nakada <nobu / ruby-lang.org> writes:
> 
> |majorの桁数を増やすとFreeBSDみたいな事態に陥りそうです。しかし、
> |これを機にminorとteenyは桁数増やしませんか。
> 
> 2.00.00 とか? なんだかかっこ悪いなあ。
それは2.0.0で良いと思うのですが、固定桁数が前提ですか?
それとも 2.10.15 とかでもかっこ悪いということでしょうか。

(桁数を増やそうと言っているわけではありません。)

-- 
神戸 隆博 (かんべ たかひろ)		at 仕事場 

44626 "NARUSE, Yui" <naruse airemix.jp> (2011-10-19 15:07:16 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
2011年10月18日17:43 Yusuke Endoh <mame / tsg.ne.jp>:
> 2011年10月18日15:27 NARUSE, Yui <naruse / airemix.jp>:
>> = リリースエンジニアリングチームの導入
>>
>> 1.9.2 での mame さんの活躍や、1.9.3 での kosaki さんの活躍を鑑みるに、
>> 要するに一人じゃリリースは困難だと思うのです。
>>
>> 一方でその場で気づいた人が backport という方針だと、今度は「フリーズ後は
>> release manager の許可無く backport しないこと」の縛りが形骸化するので、
>> これを「release engineering team の許可無く」に変えよう、というわけです。
>
> 話がおかしい気がするのですが、その「活躍」は backport 作業の
> 話ではない気がします。私はほとんど backport した覚えがないし。

今回 kosaki さんはいくつか backport していますね。
わたしも 2 個やったかな。

> ブランチ管理とかアナウンスとかチケット処理の事務作業、つまり
> リリースエンジニアリングはチーム制でやればいいと思います。
>
> でも、意思決定が大きく関わること、つまりリリースマネジメント
> にチーム制は向いていないと思います。指揮系統があいまいになる
> ので。

「決定」をするのは一人というのには同意します。
ので、「リーダー」というか「ボス」というかそういう存在は決める必要があると思っています。

> 具体的には、「状況を見てスケジュールを見直す (バグの重大度と
> 修正期間を予想してリリース延期を決める)」とか「マイルストーン
> ごとにアナウンス出す (or 誰かに出せと指示する)」とか。
> 大きな機能を取り入れるかどうかの議論のファシリテートと、決定
> なんかも仕事だと思います。

スケジュールの draft を考えるとか、アナウンスを投げたり文面考えるのも
本質的には release manager の仕事である必要はないと思うんですよ。
端的に言うと、「決め」以外は個人に依存しないようにしたいのです。

> backport の話でも、バグかどうか微妙なときに判断を下す人は必要
> なんじゃないかと。

はい、「裁定者」は一人だけである必要があります。

> ただ、すでにスケジュールが決まっていて、本当に文字通り、
> 「何があろうとこの日付に出す」のだったら、リリースマネジメ
> ントでやることはあまりなさそうではありますが。
> この成瀬さんのメールでリリースマネジメント半分終わりというか。

バグがどうしても取れないけどどうしよう、とかがありえるパターンですかねぇ。

http://yugui.jp/articles/633 yuguiさんが過去のリリースマネージメントをまとめていたので
ついでに書いておく。

> 現状の問題は、単に Yugui さんが忙しすぎるというだけだと思い
> ます。そういう場合はリリースマネージャの権限ごと他人に渡す
> べきだと思います。

Yugui さんが忙しいのもそうなんですが、じゃあリリースマネージャの権限を
渡すので誰かどうぞと言われて、誰かやりますかね。
この話は、自分がやるとしたらこういうのがないとつらいって動機で振りました。

> まとめると、
>
>  - リリースマネージャ制度自体は今まで通りでよい
>  - リリースマネージャは事務作業でもっと他人を使うべき
>  - 判断・指示すらできなくなったらリリースマネージャを
>    辞めるべき
>
> 少しきつい言い方になってますが、今までの Yugui さんの功績を
> 否定するつもりはありません。
> redmine とか定着させたのはとてもすばらしい。

いや、まぁ、要するに Matz じゃダメだったから Yugui さんならどうかと思ったけど、
Yugui さんでも無理で、じゃあもう誰がやっても無理なんじゃね?ってのがこの話でして。

例えば mame さんかその他どなたかが 2.0 のリリースマネージャを現行制度で
やるというのでしたら、それがうまくいっている間はそれで良いと思いますよ。

-- 
NARUSE, Yui  <naruse / airemix.jp>

44627 Urabe Shyouhei <shyouhei ruby-lang.org> (2011-10-19 18:12:01 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
On 10/18/2011 10:16 PM, Yukihiro Matsumoto wrote:
> バージョン番号なんて飾りなんで、上げたいと思ったときに上げる
> のが良いのだと思います。そういう意味では以前のまま。

バージョン番号が飾りなのはまあ否定しませんが、飾りだからといって
どうでもいいというのは違うでしょう。飾りが気になる人もいるのです。

飾り=感情を喚起するものだという認識まで達しているのですから、あ
とはどういう方向性で人々を扇動するかです。上げたいと思ったときに
上げるというのはいかにも弱い。

44628 "NARUSE, Yui" <naruse airemix.jp> (2011-10-19 18:23:54 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
2011年10月18日22:16 Yukihiro Matsumoto <matz / ruby-lang.org>:
> まつもと ゆきひろです
>
> In message "Re: [ruby-dev:44618] Re: Ruby 2.0 release plan"
>    on Tue, 18 Oct 2011 19:47:32 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes:
>
> |> |MAJOR: (ABI の) 後方互換性を切るときに上げる
> |> |MINOR: 後方互換性を保ったリリースの際に上げる
> |> |TEENY: 常に 0
> |> |PATCHLEVEL: リリースブランチについて、patch 1 つにつき 1 つ加算
> |>
> |> あんまりルールをきっちり決めるのは好きじゃない(完了主義にな
> |> りがちだから)のですが。
> |
> |これは第一には「1.9 までの規則と違うよ!」って意味ですね。
> |前提として現在までの1年以上間を置くリリースを踏襲するってのがあるので、
> |そこが変わった場合はまた違った形になるかもしれません。
>
> バージョン番号なんて飾りなんで、上げたいと思ったときに上げる
> のが良いのだと思います。そういう意味では以前のまま。あえてルー
> ルを決めるとしたら、原則として、
>
>  PATCHLEVEL バグフィックスのみ
>  TEENY バグ以外の変更をリリースする時
>  MONOR TEENYが9になった次、またはより大きな変更した時
>  MAJOR なんか決心した時
>
> くらいでいいような。

いやー、バージョン番号が飾りなのは否定はしませんが、
一方でインターフェイスの一つでもあるのですよ。
例えば、ruby-coreでは「1.9は1.8からのマイナーバージョンアップなのになんでこんな違うんだふざけんな」
みたいなメールがしばしばあって、そのたびに「いやそれメジャーバージョンアップなんだよ」
などと返事したりしてるわけです。

また、Semantic Versioningってのがありまして、これ自体の良し悪しについての評価は避けますが、
まぁこれを期待している人は多い、かも。

ので、「今後1.8→1.9級の変更があったらその時はMAJORを変える」というのは譲りたくない所だったり。

-- 
NARUSE, Yui  <naruse / airemix.jp>

44629 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-20 02:43:23 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
まつもと ゆきひろです

In message "Re: [ruby-dev:44627] Re: Ruby 2.0 release plan"
    on Wed, 19 Oct 2011 18:12:01 +0900, Urabe Shyouhei <shyouhei / ruby-lang.org> writes:

|On 10/18/2011 10:16 PM, Yukihiro Matsumoto wrote:
|> バージョン番号なんて飾りなんで、上げたいと思ったときに上げる
|> のが良いのだと思います。そういう意味では以前のまま。
|
|バージョン番号が飾りなのはまあ否定しませんが、飾りだからといって
|どうでもいいというのは違うでしょう。飾りが気になる人もいるのです。
|
|飾り=感情を喚起するものだという認識まで達しているのですから、あ
|とはどういう方向性で人々を扇動するかです。上げたいと思ったときに
|上げるというのはいかにも弱い。

いや、そういう意見があるのはわかってて、続く「原則」を書いた
わけです。それじゃ不満だと?

再掲します。

 PATCHLEVEL バグフィックスのみ
 TEENY バグ以外の変更をリリースする時
 MONOR TEENYが9になった次、またはより大きな変更した時
 MAJOR なんか決心した時

将来のことはわからないのに、これ以上の決定は不要だと思います
が。たとえば「リリースを原則6ヶ月ごとに行う」とかの運用もあ
り得るとは思いますが、今決める必要がある?

                                まつもと ゆきひろ /:|)

44630 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-20 02:51:00 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
まつもと ゆきひろです

In message "Re: [ruby-dev:44628] Re: Ruby 2.0 release plan"
    on Wed, 19 Oct 2011 18:23:54 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes:

|いやー、バージョン番号が飾りなのは否定はしませんが、
|一方でインターフェイスの一つでもあるのですよ。
|例えば、ruby-coreでは「1.9は1.8からのマイナーバージョンアップなのになんでこんな違うんだふざけんな」
|みたいなメールがしばしばあって、そのたびに「いやそれメジャーバージョンアップなんだよ」
|などと返事したりしてるわけです。
|
|また、Semantic Versioningってのがありまして、これ自体の良し悪しについての評価は避けますが、
|まぁこれを期待している人は多い、かも。
|
|ので、「今後1.8→1.9級の変更があったらその時はMAJORを変える」というのは譲りたくない所だったり。

予見しうる範囲内の将来では、「1.8→1.9級の変更」はありません。
だから、今、決める必要はないというのが私の考え。

で、「多くの人がソフトウェアバージョンのつけ方に期待する共通
の何かがあって、それに従うことにメリットがある」というような
ことなのであれば、まず、その「共通の何か」を定義してください
ませ。根拠と共に。

私の観測してきた範囲内では、ソフトウェアのバージョンのつけ方
なんてソフトウェアごとにバラバラで、共通のものを期待するだけ
無駄ってのが、私の認識なのですが、それは古い認識で今では
「Semantic Versioning」とかいうような「共通の何か」が常識化し
てるんでしょうかね。

                                まつもと ゆきひろ /:|)

44631 Urabe Shyouhei <shyouhei ruby-lang.org> (2011-10-20 03:31:40 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
たとえば2.0の次のバージョン番号はどうしますか?

厳格な運用を求めているわけではありませんので、2.1を出すと
言っておいて出てみたら3.0だったとかでも全然構いませんが、
しかし方針を共有しておかないと2.0の後は一挙にカオスになっ
てしまうでしょう。現在の1.8.8のように。

将来のことは分かりませんというのは将来のことは考えても無
駄ってのとは違うと信じています。逆で、将来のことは考えて
おかないといけない上に、予想通りにはいかないことも受け入
れないといけない。

44633 "NARUSE, Yui" <naruse airemix.jp> (2011-10-20 12:24:10 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
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>

44634 Takahiro Kambe <taca back-street.net> (2011-10-20 12:26:27 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
In message <CAK6Hhsqwv0wh8OVBb3Z5BQrh3-7dLHhL-pXvW+CBv8U1rayYZg / mail.gmail.com>
	on Thu, 20 Oct 2011 12:24:10 +0900,
	"NARUSE, Yui" <naruse / airemix.jp> wrote:
> しかし、ふと忘れてたんですが、major はあと 7 回しか上げられないので、
> もっとケチらないとダメですね。
素朴な疑問なのですが、その頃までも「1桁」の制約を受けるのでしょうか?

-- 
神戸 隆博 (かんべ たかひろ)		at 仕事場 

44636 Ayumu Aizawa <ayumu.aizawa gmail.com> (2011-10-20 13:26:33 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
あいざわです

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

---
 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>
>
>

44637 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-20 13:36:56 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
まつもと ゆきひろです

In message "Re: [ruby-dev:44631] Re: Ruby 2.0 release plan"
    on Thu, 20 Oct 2011 03:31:40 +0900, Urabe Shyouhei <shyouhei / ruby-lang.org> writes:

|たとえば2.0の次のバージョン番号はどうしますか?

えーと、[ruby-dev:44619] の基準でなんの不満が?

|厳格な運用を求めているわけではありませんので、2.1を出すと
|言っておいて出てみたら3.0だったとかでも全然構いませんが、
|しかし方針を共有しておかないと2.0の後は一挙にカオスになっ
|てしまうでしょう。現在の1.8.8のように。

よくわかんないです。私が繰り返し出してる基準や方針で不満なら、
どう不満で、どうして欲しいのか明言してください。私が何の方針
も出してないかのような物言いは不愉快です。

# モヒカンモード

44638 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-20 13:45:33 +0900) Re: Ruby 2.0 release plan

まつもと ゆきひろです

なんでこの二人には伝わらない。

In message "Re: [ruby-dev:44633] Re: Ruby 2.0 release plan"
    on Thu, 20 Oct 2011 12:24:10 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes:

|比較的近い未来だと、2.0.0 の次をどうするかと、
|MVM が 2.0.0 に入らないとして、入った時どうなるのか、とか。

I cannot judge correctly because I'm not the man who knows all about MVM. I heard that MVM keep source level backward compatibility, it could be the TEENY version up.

If you don't like [ruby-dev:44619], how about Aizawa-san's rule in [ruby-dev:44636]?

|卜部さんと同意見です。
|加えて、バージョン番号は実は soname や lib/ruby 下のファイル名などに影響したり、
|今どのくらいの非互換をつっこんでいいのかにも影響するので。

いや、そういうのがもうイヤなんですよ。なんでバージョン番号が
先になるのか。これ以上、バージョン番号なんてくだらないことで
進歩が遅くなるのはたくさんです。技術的にsonameが変える必要が
あれば、その要求を満たすようにバージョン番号を上げたらいいし、
非互換を突っ込みたくて、それをバージョンで明示したいなら上げ
たらいいじゃないですか。

リリースするたびに「このリリースはマーケティングの観点から
TEENYを上げるべきか、MINORを上げるべきか」って議論すればそれ
でいいじゃないかと思うんですが。

                                まつもと ゆきひろ /:|)

Refine translation
まつもと ゆきひろです

なんでこの二人には伝わらない。

In message "Re: [ruby-dev:44633] Re: Ruby 2.0 release plan"
    on Thu, 20 Oct 2011 12:24:10 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes:

|比較的近い未来だと、2.0.0 の次をどうするかと、
|MVM が 2.0.0 に入らないとして、入った時どうなるのか、とか。

私は MVM について全容を把握しているわけじゃないんで、今それ
を決めろと言われても。ソース互換性があるらしいから TEENY で
いいんじゃないですか。

[ruby-dev:44619] で不満なら、あいざわさんの [ruby-dev:44636]
ではどうでしょう?

|卜部さんと同意見です。
|加えて、バージョン番号は実は soname や lib/ruby 下のファイル名などに影響したり、
|今どのくらいの非互換をつっこんでいいのかにも影響するので。

いや、そういうのがもうイヤなんですよ。なんでバージョン番号が
先になるのか。これ以上、バージョン番号なんてくだらないことで
進歩が遅くなるのはたくさんです。技術的にsonameが変える必要が
あれば、その要求を満たすようにバージョン番号を上げたらいいし、
非互換を突っ込みたくて、それをバージョンで明示したいなら上げ
たらいいじゃないですか。

リリースするたびに「このリリースはマーケティングの観点から
TEENYを上げるべきか、MINORを上げるべきか」って議論すればそれ
でいいじゃないかと思うんですが。

                                まつもと ゆきひろ /:|)

44639 Nobuyoshi Nakada <nobu ruby-lang.org> (2011-10-20 14:14:46 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
なかだです。

(11/10/20 12:26), Takahiro Kambe wrote:
> In message <CAK6Hhsqwv0wh8OVBb3Z5BQrh3-7dLHhL-pXvW+CBv8U1rayYZg / mail.gmail.com>
> 	on Thu, 20 Oct 2011 12:24:10 +0900,
> 	"NARUSE, Yui" <naruse / airemix.jp> wrote:
>> しかし、ふと忘れてたんですが、major はあと 7 回しか上げられないので、
>> もっとケチらないとダメですね。
> 素朴な疑問なのですが、その頃までも「1桁」の制約を受けるのでしょうか?

majorの桁数を増やすとFreeBSDみたいな事態に陥りそうです。しかし、
これを機にminorとteenyは桁数増やしませんか。

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

44640 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-20 14:35:28 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
まつもと ゆきひろです

In message "Re: [ruby-dev:44639] Re: Ruby 2.0 release plan"
    on Thu, 20 Oct 2011 14:14:46 +0900, Nobuyoshi Nakada <nobu / ruby-lang.org> writes:

|majorの桁数を増やすとFreeBSDみたいな事態に陥りそうです。しかし、
|これを機にminorとteenyは桁数増やしませんか。

2.00.00 とか? なんだかかっこ悪いなあ。

2.0.0 から 2.9.9 までは最大100リリース可能なので十分じゃ
ないかと思うんですが。

まあ、仮に桁を増やすとするならば丁度よい機会だとは思うので、
他の人の意見も聞いてみたい気がします。

44642 Nobuyoshi Nakada <nobu ruby-lang.org> (2011-10-20 14:59:50 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
なかだです。

(11/10/20 14:44), Takahiro Kambe wrote:
>> |majorの桁数を増やすとFreeBSDみたいな事態に陥りそうです。しかし、
>> |これを機にminorとteenyは桁数増やしませんか。
>>
>> 2.00.00 とか? なんだかかっこ悪いなあ。
> それは2.0.0で良いと思うのですが、固定桁数が前提ですか?

[ruby-dev:44606]で触れられていますが、固定でないと単純な文字列としてバー
ジョンの比較ができなくなります。

  "2.10.15" <=> "2.8.0" #=> -1
  [2,10,15] <=> [2,8,0] #=> 1

(11/10/18 16:14), Urabe Shyouhei wrote:
> だめです。Rubyのバージョン番号には一桁でなければならないという制限があります。
> それを撤廃するなら適切にComparableをincludeしたバージョンクラスを新設する必要があるはずです。

1.8まではRUBY_VERSION_CODEというマクロがあって、これが各一桁ずつに限定
される理由の一つだったのですが、1.9からは廃止されています。ですから、現
在の制限は「同一のmajorまたはmajor+teenyの間はその下位の桁数は同じでな
ければならない」というものです。


-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

44643 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-20 15:01:10 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
まつもと ゆきひろです

In message "Re: [ruby-dev:44641] Re: Ruby 2.0 release plan"
    on Thu, 20 Oct 2011 14:44:14 +0900, Takahiro Kambe <taca / back-street.net> writes:

|> 2.00.00 とか? なんだかかっこ悪いなあ。
|それは2.0.0で良いと思うのですが、固定桁数が前提ですか?
|それとも 2.10.15 とかでもかっこ悪いということでしょうか。

かっこ悪くはありませんが、これまでずっと1.9の次が1.10なのは
「ソートできなくて嫌だ」と主張してきたので、それを引っ込める
のはどうもなあ、という感じですね。

44644 Takahiro Kambe <taca back-street.net> (2011-10-20 15:18:22 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
In message <4E9FB89D.8070508 / ruby-lang.org>
	on Thu, 20 Oct 2011 14:59:50 +0900,
	Nobuyoshi Nakada <nobu / ruby-lang.org> wrote:
> (11/10/20 14:44), Takahiro Kambe wrote:
>> それは2.0.0で良いと思うのですが、固定桁数が前提ですか?
> 
> [ruby-dev:44606]で触れられていますが、固定でないと単純な文字列としてバー
軽く読み飛ばしてました。

> ジョンの比較ができなくなります。
> 
>   "2.10.15" <=> "2.8.0" #=> -1
>   [2,10,15] <=> [2,8,0] #=> 1
なるほど、納得しました。

pkgsrcのp5-pkgsrc-Deweyパッケージを思いだしました。

-- 
神戸 隆博 (かんべ たかひろ)		at 仕事場 

44645 Ayumu Aizawa <ayumu.aizawa gmail.com> (2011-10-20 15:28:15 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
あいざわです

もしもわたしが  [ruby-dev:44636] の基準で運用するとしたら、TEENYのリリースは
どんなに頑張っても3か月に1回、MINORは1年に1回くらいしか出せないんじゃないか
と思います。

毎年おおきな追加変更があったとしても(ないとおもうけど)10年くらいは今のままで
も大丈夫で、さすがに10年の間にはまつもとさんも何らかの決心をするんじゃないか
と思っています。

44646 Urabe Shyouhei <shyouhei ruby-lang.org> (2011-10-20 20:43:45 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
On 10/20/2011 01:45 PM, Yukihiro Matsumoto wrote:
> いや、そういうのがもうイヤなんですよ。なんでバージョン番号が
> 先になるのか。これ以上、バージョン番号なんてくだらないことで
> 進歩が遅くなるのはたくさんです。

バージョン番号の数字の字面を気にしていません。その背後にあるべき骨太
の指針、今後のRubyをどうしていきたいかを決めてほしいなあと思っていま
す。

> 技術的にsonameが変える必要が
> あれば、その要求を満たすようにバージョン番号を上げたらいいし、
> 非互換を突っ込みたくて、それをバージョンで明示したいなら上げ
> たらいいじゃないですか。

だからようするに、今後のRubyに関してまつもとさんは非互換を入れたいん
ですよね。非互換を入れるなと制止されたくないのですよね。なので、やり
逃げのように非互換を入れておいてからおもむろにバージョンを考えればい
いという発想のように見受けられます。

それはそれで一つの方針ですので、(あんまり好きではありませんが)そのよ
うになさるとおっしゃるのであれば構いません。そうするのですか?

> リリースするたびに「このリリースはマーケティングの観点から
> TEENYを上げるべきか、MINORを上げるべきか」って議論すればそれ
> でいいじゃないかと思うんですが。

マーケティングはそれはそれで当然行われるべきと思います。

44668 SASADA Koichi <ko1 atdot.net> (2011-10-21 23:27:56 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
まつもとさん

 ささだです.

(2011/10/21 21:10), Yusuke Endoh wrote:
> そういうわけで遠藤は 2.0 のリリースマネージャに絶賛立候補中です!

 リリースマネージャ(トップ)を決めるといいと思うのですが,いかがでしょ
うか.もし何か,躊躇されている点があるようでしたら,仰って頂いたほうがい
いように思います.

# 早くリリースマネージャにリリースプランを宣言して欲しい.

-- 
// SASADA Koichi at atdot dot net

44647 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-20 22:31:46 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
まつもと ゆきひろです

In message "Re: [ruby-dev:44646] Re: Ruby 2.0 release plan"
    on Thu, 20 Oct 2011 20:43:45 +0900, Urabe Shyouhei <shyouhei / ruby-lang.org> writes:

|バージョン番号の数字の字面を気にしていません。その背後にあるべき骨太
|の指針、今後のRubyをどうしていきたいかを決めてほしいなあと思っていま
|す。

「今後のRubyをどうしていきたいか」って言われても。淡々と開発
を続けます、以上に言えることはないですね。開発ってそういうも
んじゃないの? そして、必要があればある程度の非互換性を導入す
ることもあり得ると思います。

|だからようするに、今後のRubyに関してまつもとさんは非互換を入れたいん
|ですよね。非互換を入れるなと制止されたくないのですよね。なので、やり
|逃げのように非互換を入れておいてからおもむろにバージョンを考えればい
|いという発想のように見受けられます。
|
|それはそれで一つの方針ですので、(あんまり好きではありませんが)そのよ
|うになさるとおっしゃるのであれば構いません。そうするのですか?

ことさらに非互換を入れたいわけではないですが、将来、必要に迫
られて非互換を導入する必要が発生したときに縛られたくはないと
は思います。

「やり逃げのように」という表現はよくわかりません。私の観点か
らは「将来、非互換の導入がないとは言えない」と認めることも、
「(技術的必要性から導入される)非互換をバージョニングの都合で
制止されるのは望ましくない」と望むことも、見通せない将来に対
する誠実な態度であって、「やり逃げ」のような非難めいた表現を
されるいわれはないと思います。うらべくんの意見を聞いてると、
バージョンが主で開発が従だと考えてるようにしか感じられないん
ですが、気のせいかな。

これが「やり逃げ」のような望ましくない方針であるとおっしゃる
のであれば、望ましいものとしてどのような方針を想定しているの
か具体的に聞かせていただきたいものです。もちろん、将来どのよ
うな非互換性が導入されるのか、そもそも導入されるのかどうかさ
え現時点では不確定である、という事実と、将来の言語の進歩を妨
げるようなルールは害悪でしかないという点も考慮に入れてくださ
るとありがたいです。

                                まつもと ゆきひろ /:|)

44649 "NARUSE, Yui" <naruse airemix.jp> (2011-10-20 23:29:20 +0900) Re: Ruby 2.0 release plan

(2011/10/20 13:36), Yukihiro Matsumoto wrote:
> まつもと ゆきひろです
> 
> In message "Re: [ruby-dev:44631] Re: Ruby 2.0 release plan"
>     on Thu, 20 Oct 2011 03:31:40 +0900, Urabe Shyouhei <shyouhei / ruby-lang.org> writes:
> 
> |たとえば2.0の次のバージョン番号はどうしますか?
> 
> えーと、[ruby-dev:44619] の基準でなんの不満が?
> 
> |厳格な運用を求めているわけではありませんので、2.1を出すと
> |言っておいて出てみたら3.0だったとかでも全然構いませんが、
> |しかし方針を共有しておかないと2.0の後は一挙にカオスになっ
> |てしまうでしょう。現在の1.8.8のように。
> 
> よくわかんないです。私が繰り返し出してる基準や方針で不満なら、
> どう不満で、どうして欲しいのか明言してください。私が何の方針
> も出してないかのような物言いは不愉快です。
> 
> # モヒカンモード


The problem is the rule [ruby-dev:44619] doesn't work except Matz.

For example,

> PATCHLEVEL バグフィックスのみ
> TEENY バグ以外の変更をリリースする時
> MONOR TEENYが9になった次、またはより大きな変更した時

How can we recognize this is 'bigger' change.

> MAJOR なんか決心した時

When we should judge 'it should be MAJOR release'?

[ruby-dev:44636] can be some examples and it works for us.

-- 
NARUSE, Yui  <naruse / airemix.jp>

Refine translation
(2011/10/20 13:36), Yukihiro Matsumoto wrote:
> まつもと ゆきひろです
> 
> In message "Re: [ruby-dev:44631] Re: Ruby 2.0 release plan"
>     on Thu, 20 Oct 2011 03:31:40 +0900, Urabe Shyouhei <shyouhei / ruby-lang.org> writes:
> 
> |たとえば2.0の次のバージョン番号はどうしますか?
> 
> えーと、[ruby-dev:44619] の基準でなんの不満が?
> 
> |厳格な運用を求めているわけではありませんので、2.1を出すと
> |言っておいて出てみたら3.0だったとかでも全然構いませんが、
> |しかし方針を共有しておかないと2.0の後は一挙にカオスになっ
> |てしまうでしょう。現在の1.8.8のように。
> 
> よくわかんないです。私が繰り返し出してる基準や方針で不満なら、
> どう不満で、どうして欲しいのか明言してください。私が何の方針
> も出してないかのような物言いは不愉快です。
> 
> # モヒカンモード

ええと、端的に言うと [ruby-dev:44619] って基準になってないんですよ、
まつもとさん以外には。具体的には、

> PATCHLEVEL バグフィックスのみ
> TEENY バグ以外の変更をリリースする時
> MONOR TEENYが9になった次、またはより大きな変更した時

「より大きな」の基準は何なのでしょう。

> MAJOR なんか決心した時

要するにどういう時なんですか。

で、これを解釈してみた例がたとえば [ruby-dev:44636] になるわけで、
これだと第三者にも理解可能ですね。

-- 
NARUSE, Yui  <naruse / airemix.jp>

44650 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-20 23:36:18 +0900) Re: Ruby 2.0 release plan

まつもと ゆきひろです

In message "Re: [ruby-dev:44649] Re: Ruby 2.0 release plan"
    on Thu, 20 Oct 2011 23:29:20 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes:

|ええと、端的に言うと [ruby-dev:44619] って基準になってないんですよ、
|まつもとさん以外には。

Do you realy need such objective rules? Do you want to be bureaucratic? 
「目安」としては十分だと思うけど。

|で、これを解釈してみた例がたとえば [ruby-dev:44636] になるわけで、
|これだと第三者にも理解可能ですね。

Ok, [ruby-dev:44636] works for you. no problem. I don't claim its not what I meant.

Refine translation
まつもと ゆきひろです

In message "Re: [ruby-dev:44649] Re: Ruby 2.0 release plan"
    on Thu, 20 Oct 2011 23:29:20 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes:

|ええと、端的に言うと [ruby-dev:44619] って基準になってないんですよ、
|まつもとさん以外には。

なんでそんな客観的な基準を欲しがるの? 官僚主義になりたいの?
「目安」としては十分だと思うけど。

|で、これを解釈してみた例がたとえば [ruby-dev:44636] になるわけで、
|これだと第三者にも理解可能ですね。

んじゃ、それでいいじゃん。私も別に [ruby-dev:44636] は私の意
図を反映してないなんて言うつもりはないです。

44651 "NARUSE, Yui" <naruse airemix.jp> (2011-10-20 23:39:22 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
(2011/10/20 22:31), Yukihiro Matsumoto wrote:
> |だからようするに、今後のRubyに関してまつもとさんは非互換を入れたいん
> |ですよね。非互換を入れるなと制止されたくないのですよね。なので、やり
> |逃げのように非互換を入れておいてからおもむろにバージョンを考えればい
> |いという発想のように見受けられます。
> |
> |それはそれで一つの方針ですので、(あんまり好きではありませんが)そのよ
> |うになさるとおっしゃるのであれば構いません。そうするのですか?
> 
> ことさらに非互換を入れたいわけではないですが、将来、必要に迫
> られて非互換を導入する必要が発生したときに縛られたくはないと
> は思います。
> 
> 「やり逃げのように」という表現はよくわかりません。私の観点か
> らは「将来、非互換の導入がないとは言えない」と認めることも、
> 「(技術的必要性から導入される)非互換をバージョニングの都合で
> 制止されるのは望ましくない」と望むことも、見通せない将来に対
> する誠実な態度であって、「やり逃げ」のような非難めいた表現を
> されるいわれはないと思います。うらべくんの意見を聞いてると、
> バージョンが主で開発が従だと考えてるようにしか感じられないん
> ですが、気のせいかな。
> 
> これが「やり逃げ」のような望ましくない方針であるとおっしゃる
> のであれば、望ましいものとしてどのような方針を想定しているの
> か具体的に聞かせていただきたいものです。もちろん、将来どのよ
> うな非互換性が導入されるのか、そもそも導入されるのかどうかさ
> え現時点では不確定である、という事実と、将来の言語の進歩を妨
> げるようなルールは害悪でしかないという点も考慮に入れてくださ
> るとありがたいです。

わたしは、バージョンはプログラムの実態を反映するべきという考えなので、
非互換を入れてからバージョンを合わせるというのでも異論はありませんが、
非互換を入れた場合はそれに自覚的であっては頂きたいですね。

逆に言うと、自覚的であるためにはどういう場合には自覚しないといけないかを
事前に決める必要があると言うことになるわけです。

-- 
NARUSE, Yui  <naruse / airemix.jp>

44653 "NARUSE, Yui" <naruse airemix.jp> (2011-10-21 00:47:03 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
(2011/10/20 23:36), Yukihiro Matsumoto wrote:
> まつもと ゆきひろです
> 
> In message "Re: [ruby-dev:44649] Re: Ruby 2.0 release plan"
>     on Thu, 20 Oct 2011 23:29:20 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes:
> 
> |ええと、端的に言うと [ruby-dev:44619] って基準になってないんですよ、
> |まつもとさん以外には。
> 
> なんでそんな客観的な基準を欲しがるの? 官僚主義になりたいの?
> 「目安」としては十分だと思うけど。

ヒューマンインターフェイスとしてのバージョン番号は別に気分で決めてもいいんですが、
soname や lib/ruby/x.x は設計の対象なのですよ。
実際に 1.9 になってからこれらについては何度か物議の対象となっていて、例えば以下とか。
http://arika.org/2009/01/17/ruby-1-9-1%E3%80%9C%E3%82%92%E6%A7%8B%E6%88%90%E3%81%99%E3%82%8B%E4%B8%89%E3%81%A4%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3
http://redmine.ruby-lang.org/issues/3850
http://redmine.ruby-lang.org/issues/4666
http://lists.debian.org/debian-ruby/2010/04/msg00022.html
これ以外にも単発での質問は何度かruby-core に来てましたし、
先日香り屋さんからも質問されましたね。

この辺の議論を重ねているわたしや卜部さんの感覚では、バージョンは意外と影響範囲が
大きいものなので、おっかなびっくりな感覚になるのです。

もっとも、このスレでの流れを鑑みるに、
* バージョンはマーケティングの観点のみから決めたい
* 非互換変更が入ったか気にしたくない
という意見が多いようなので、soname や API VERSION、LIB VERSION など、
は毎回 major を上げるという運用になるのですかね。

その運用に異議が内容ならば他の部分も変えてしまいます。

-- 
NARUSE, Yui  <naruse / airemix.jp>

44654 "U.Nakamura" <usa garbagecollect.jp> (2011-10-21 02:49:15 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
こんにちは、なかむら(う)です。

1箇所だけ反応しておこうかな。

In message "[ruby-dev:44620] Re: Ruby 2.0 release plan"
    on Oct.18,2011 23:03:42, <mame / tsg.ne.jp> wrote:
> >> もう 2.0 では binary compatiblity にこだわるのをやめません?
> >> ABI の後方互換性が崩れても C ソースレベルで互換性があれば、
> >> リビルドすれば済むわけなので、リビルドしてください、という
> >> ことで。
> >
> > 「こだわらない」とはどのような意味ですか。
> > 「リビルドしてください」と言うには後方互換性が崩れたことを知る必要があるわけですが。
> 
> 常に崩れている (可能性がある) ので、必ずリビルドしてください
> ということです。
> 
> > Windows ではどうするのでしょう。
> 
> バイナリ gem かあ。
> MINOR リリースごとに gem リリースしてください、かなあ。
> 警告出した上で古い gem を使えるようにしてもいいかもですが。
> ffi 化を進めたくなる気持ちがわかりますね。

どうせそんなに頻繁にRubyがリリースされるわけでもないでしょう
から、Windowsでもさほど問題ないんじゃないでしょうか。

たぶんRubyのリリース頻度より各gemのリリース頻度の方が一般には
高くて、gemがバイナリ提供されないと死ぬ人は

  (a) 大声でバイナリを要求する
  (b) 古いバイナリgemと心中する

のいずれかの対応を取っているはずです。

で、(a)の人はRubyがバイナリ互換壊したときもgem側に同じことを
するでしょうし、(b)の人はそもそもRubyのバージョンを上げないで
しょう。





たぶん、どうせ先っちょRubyをリリースする間隔は、頑張って1年間
隔、おそらくは2〜3年間隔になっちゃうような気がするので、それ
だけ経ったらどれだけ変更が積み重なるのかを考えたら、バイナリ
互換性の維持自体が困難なんじゃないかなー。
ならば最初からそんな縛りは諦めといた方が開発が楽になるんじゃ
ないかしら。


それでは。
-- 
U.Nakamura <usa / garbagecollect.jp>


44656 Yusuke Endoh <mame tsg.ne.jp> (2011-10-21 12:37:07 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
遠藤です。

2011年10月21日0:47 NARUSE, Yui <naruse / airemix.jp>:
> ヒューマンインターフェイスとしてのバージョン番号は別に気分で決めてもいいんですが、
> soname や lib/ruby/x.x は設計の対象なのですよ。
> 実際に 1.9 になってからこれらについては何度か物議の対象となっていて、例えば以下とか。
> http://arika.org/2009/01/17/ruby-1-9-1%E3%80%9C%E3%82%92%E6%A7%8B%E6%88%90%E3%81%99%E3%82%8B%E4%B8%89%E3%81%A4%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3
> http://redmine.ruby-lang.org/issues/3850
> http://redmine.ruby-lang.org/issues/4666
> http://lists.debian.org/debian-ruby/2010/04/msg00022.html
> これ以外にも単発での質問は何度かruby-core に来てましたし、
> 先日香り屋さんからも質問されましたね。


物議になっているのは、単に Ruby バージョンと ABI バージョンの
見た目が似すぎているせいでしょう。Ruby バージョンと連動しない
バージョンとしては他にも Marshal がありますが、これは見た目が
大分違う (現在 4.4) ので、混乱を聞いたことがありません。

素直に考えたら、Ruby バージョンをどうこうしようではなく、ABI
バージョンの見た目を変えよう、という提案になるのが自然だと思
いました。/usr/lib/ruby/abi4.4/ とか。


> もっとも、このスレでの流れを鑑みるに、
> * バージョンはマーケティングの観点のみから決めたい
> * 非互換変更が入ったか気にしたくない
> という意見が多いようなので、


要するに Ruby バージョン (TEENY まで含めて) と ABI バージョンを
一致させちゃおう、という意見ですね。


> その運用に異議が内容ならば他の部分も変えてしまいます。


他の部分とは?

-- 
Yusuke Endoh <mame / tsg.ne.jp>

44669 Masaya TARUI <tarui prx.jp> (2011-10-22 06:25:09 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
2011年10月20日23:36 Yukihiro Matsumoto <matz / ruby-lang.org>:
> んじゃ、それでいいじゃん。私も別に [ruby-dev:44636] は私の意
> 図を反映してないなんて言うつもりはないです。

[ruby-dev:44636]++
官僚主義になりたい訳ではないですが、1.9のバージョニングがいまいち窮屈だった感じが
するので今のうちに予防線を張っておきたい所です。

この位の目安があった方がC拡張使っているgem作者もTEENY上がる時にコンパイルし直しが
必要かもしれないとか分かりやすくてよいと思います。

ABI互換をうたうったのは管理の面でも機能追加の面でも足を引っ張って結果的にはそんなによくなかった。

RUBY_VERSIONに時間を取られるのもいまいちなのは同意なので、
[ruby-dev:44636]が共通認識になると嬉しい。

所でrelease planのスレッドでこんな事を話しているので
違和感があるのかもしれません。
2.0のイニシャルリリースには直接関係ない事なのでスレッドを分けるべきでしょうか。

-- 
樽家昌也(Masaya TARUI)
No Tool,No Life.

44658 Nobuyoshi Nakada <nobu ruby-lang.org> (2011-10-21 13:30:29 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
なかだです。

(11/10/20 13:26), Ayumu Aizawa wrote:
>  TEENY 機能追加したとき
>  - 新しいクラスやメソッドの追加、大きな改善

この方針だとあっという間に溢れそうな気がします。

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

44661 Ayumu Aizawa <ayumu.aizawa gmail.com> (2011-10-21 17:40:05 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
あいざわです

> (11/10/20 13:26), Ayumu Aizawa wrote:
>>  TEENY 機能追加したとき
>>  - 新しいクラスやメソッドの追加、大きな改善
>
> この方針だとあっという間に溢れそうな気がします。

2.0.0は成瀬さんの案でよいとおもうのですが、その後の2.0系列については、リリース候補月を
あらかじめ決めておいて、そこ以外でのリリースは行わない方針を考えていました。
(セキュリティ対応など緊急の場合はパッチリリースで対応)

例えば2.0系列でのリリース最短サイクルを4ケ月とした場合、2.0.1がリリースされるのはどんなに
早くても2013年8月、その次は2013年12月、その次は2014年4月 ... となります。
各リリースポイントの2ケ月前に、リリース判定ポイントをおき、次のリリースポイントでリリースを
おこなうかどうかを判断します。

判断基準は
 - 次のリリースに含めたい機能が判断ポイントまでに十分なテストが行われているか
 - 次のリリースをおこなうにあたって、十分なリソース(リリースエンジニアリングチーム)が編成できるか
などを鑑みて、リリースマネジャーがTEENY(またはMINOR)を上げるようなリリースをするか
しないかを判定します。

リリースするという判断をした場合は、リリースエンジニアリングにリリースまでにやらなければならない
作業を明示して、それがリリースポイントの1ケ月前までにクローズしていれば最終的にリリースを実施
するプロセスに入ります。

リリースしないという判断をした場合は、その回のリリースは見送られるか、単にバグ修正を集積した
パッチリリースのみをおこないます。

44662 "NARUSE, Yui" <naruse airemix.jp> (2011-10-21 17:40:05 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
2011年10月21日12:37 Yusuke Endoh <mame / tsg.ne.jp>:
> 2011年10月21日0:47 NARUSE, Yui <naruse / airemix.jp>:
>> ヒューマンインターフェイスとしてのバージョン番号は別に気分で決めてもいいんですが、
>> soname や lib/ruby/x.x は設計の対象なのですよ。
>> 実際に 1.9 になってからこれらについては何度か物議の対象となっていて、例えば以下とか。
>> http://arika.org/2009/01/17/ruby-1-9-1%E3%80%9C%E3%82%92%E6%A7%8B%E6%88%90%E3%81%99%E3%82%8B%E4%B8%89%E3%81%A4%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3
>> http://redmine.ruby-lang.org/issues/3850
>> http://redmine.ruby-lang.org/issues/4666
>> http://lists.debian.org/debian-ruby/2010/04/msg00022.html
>> これ以外にも単発での質問は何度かruby-core に来てましたし、
>> 先日香り屋さんからも質問されましたね。
>
>
> 物議になっているのは、単に Ruby バージョンと ABI バージョンの
> 見た目が似すぎているせいでしょう。Ruby バージョンと連動しない
> バージョンとしては他にも Marshal がありますが、これは見た目が
> 大分違う (現在 4.4) ので、混乱を聞いたことがありません。

Marshalバージョンはもう何年も変えていないので例として適切かは
わからないのですが、そのような方針はあると思います。

> 素直に考えたら、Ruby バージョンをどうこうしようではなく、ABI
> バージョンの見た目を変えよう、という提案になるのが自然だと思
> いました。/usr/lib/ruby/abi4.4/ とか。

そこは ABI バージョンでなく、RUBY_LIB_VERSION ですね。
なお、Ruby のバージョンと関係ないものにした場合、
Ruby 2.0 系と Ruby 2.1 系が走った場合に重複しないようにするのが
ちょっと大変になる、かも。

>> もっとも、このスレでの流れを鑑みるに、
>> * バージョンはマーケティングの観点のみから決めたい
>> * 非互換変更が入ったか気にしたくない
>> という意見が多いようなので、
>
>
> 要するに Ruby バージョン (TEENY まで含めて) と ABI バージョンを
> 一致させちゃおう、という意見ですね。

「ABI バージョンなど」ですね。

>> その運用に異議が内容ならば他の部分も変えてしまいます。
>
>
> 他の部分とは?

直前に書いている通り「soname や API VERSION、LIB VERSION など」です。
具体的には include/ruby/version.h のRUBY_API_VERSION_* とか。
soname を常に3桁にしたりとか。

-- 
NARUSE, Yui  <naruse / airemix.jp>

44663 Ayumu Aizawa <ayumu.aizawa gmail.com> (2011-10-21 17:42:47 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
補足
各リリースポイントでは、いくつの機能追加があったとしてもTEENY(またはMINOR)は1づつしか
増やさない想定です。

44664 Ayumu Aizawa <ayumu.aizawa gmail.com> (2011-10-21 17:49:21 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
あいざわです。

>> もっとも、このスレでの流れを鑑みるに、
>> * バージョンはマーケティングの観点のみから決めたい
>> * 非互換変更が入ったか気にしたくない
>> という意見が多いようなので、
>
>
> 要するに Ruby バージョン (TEENY まで含めて) と ABI バージョンを
> 一致させちゃおう、という意見ですね。
>

各バージョンの番号をどうするか悩むのも面倒なので、TEENYレベルが変更
になった時は、仮にその必要がなくても全部一緒に上げてしまうと割り切って
しまってよいと思いました。

乱暴すぎるかな?

44665 Yusuke Endoh <mame tsg.ne.jp> (2011-10-21 21:10:42 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
遠藤です。

2011年10月19日15:07 NARUSE, Yui <naruse / airemix.jp>:
>> 具体的には、「状況を見てスケジュールを見直す (バグの重大度と
>> 修正期間を予想してリリース延期を決める)」とか「マイルストーン
>> ごとにアナウンス出す (or 誰かに出せと指示する)」とか。
>> 大きな機能を取り入れるかどうかの議論のファシリテートと、決定
>> なんかも仕事だと思います。
>
> スケジュールの draft を考えるとか、アナウンスを投げたり文面考えるのも
> 本質的には release manager の仕事である必要はないと思うんですよ。
> 端的に言うと、「決め」以外は個人に依存しないようにしたいのです。


なるほど。完全に同意です。


>> 現状の問題は、単に Yugui さんが忙しすぎるというだけだと思い
>> ます。そういう場合はリリースマネージャの権限ごと他人に渡す
>> べきだと思います。
>
> Yugui さんが忙しいのもそうなんですが、じゃあリリースマネージャの権限を
> 渡すので誰かどうぞと言われて、誰かやりますかね。
> この話は、自分がやるとしたらこういうのがないとつらいって動機で振りました。


自分がリリースマネージャをやるとしても、「リリースブランチに
コミットしていいのは原則リリースマネージャだけ」というルール
はやめますね。というか無理。
「誰かこれ判断してー」とか、「バックポートもしといてー」とか、
「誰かアナウンスの文面作ってー」とか適宜言うつもりでしたが、
チームを決めた方がいいのかな。いいような気もする。


> 例えば mame さんかその他どなたかが 2.0 のリリースマネージャを現行制度で
> やるというのでしたら、それがうまくいっている間はそれで良いと思いますよ。


そういうわけで遠藤は 2.0 のリリースマネージャに絶賛立候補中です!

-- 
Yusuke Endoh <mame / tsg.ne.jp>

44666 Yusuke Endoh <mame tsg.ne.jp> (2011-10-21 21:13:02 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
遠藤です。

2011年10月21日17:40 NARUSE, Yui <naruse / airemix.jp>:
>> 物議になっているのは、単に Ruby バージョンと ABI バージョンの
>> 見た目が似すぎているせいでしょう。Ruby バージョンと連動しない
>> バージョンとしては他にも Marshal がありますが、これは見た目が
>> 大分違う (現在 4.4) ので、混乱を聞いたことがありません。
>
> Marshalバージョンはもう何年も変えていないので例として適切かは
> わからないのですが、そのような方針はあると思います。

まあ、Marshal バージョンにはほとんどの人が興味を持ってなさそう
ではあります。
かくいう私も間違えてた。正しくは 4.8 でした。すみません。


>> 要するに Ruby バージョン (TEENY まで含めて) と ABI バージョンを
>> 一致させちゃおう、という意見ですね。
>
> 「ABI バージョンなど」ですね。
>
>>> その運用に異議が内容ならば他の部分も変えてしまいます。
>>
>>
>> 他の部分とは?
>
> 直前に書いている通り「soname や API VERSION、LIB VERSION など」です。
> 具体的には include/ruby/version.h のRUBY_API_VERSION_* とか。
> soname を常に3桁にしたりとか。

なるほど。でも、実際に作業するのは速いかも。
明確にその意見 (= Ruby バージョンと ABI バージョンなど一致させろ)
を言ってるのは遠藤だけな気がするので。
まつもとさんは「もう互換性とか気にしたくない」としか言ってなくて、
特にバイナリ互換性を捨てたがってる遠藤とは問題意識が異なるかも。


まつもとさん、[ruby-dev:44610] はどう思います?

未だに setup.rb とか使ってるユーザはアップグレード時にライブラリの
再インストールが必要になりますが、我々にとっては TEENY でもバイナリ
互換性を気にしなくてよくなる (ソースレベルの互換性はほしい) という
話です。

-- 
Yusuke Endoh <mame / tsg.ne.jp>

44667 Urabe Shyouhei <shyouhei ruby-lang.org> (2011-10-21 23:27:46 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
将来は、見通せないからこそ、制御しないといけない。そのように信じて
います。未来予想を確実に当てるには自分で未来を作ればいい。言ってる
ことは同じです。まつもとさんはどのような未来を考えていますか。今、
Rubyはたくさんのコミッターがいて、まつもとさんが「じゃあGIL捨てよ
う」とか「generational incremental parallel garbage collector希望」
とか「JIT欲しい」とか言えばみんなでそちらに向かって頑張っていける
じゃないですか。将来は見通せないからといって何もビジョンを示さない
ことのほうがよほど不誠実だと思いますね。プロジェクトリーダーの態度
として。

バージョン番号の話に戻りますけど、バージョン番号は飾りで、ただの数
字で、あまり意味がない、ここまでは認識を共有できていると思います。
しかるに、たとえばバージョンを2.0.0に上げるだけでこれだけ喜んでる
人がいるのはなんなのか。
https://github.com/ruby/ruby/commit/6b8d4ab
これが飾りの効果ですね。今はまだ実態がない2.0というものにこれだけ
のリアクションがあるという事実に自覚的になるべきです。バージョン番
号に意味はないからこそ、ここぞというタイミングで使うととてもよく効
くわけです。じゃあ、今後、これをどう使いましょうか。次のバージョン
にどういうメッセージを持たせますか?

バージョンが主なのではありません。開発方針が主なのです。それを考え
ればバージョン計画は出てくるし、開発も進む。開発が先にくるのは、た
だのカオスです。

44670 "NARUSE, Yui" <naruse airemix.jp> (2011-10-22 17:05:26 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
(2011/10/22 6:25), Masaya TARUI wrote:
> 2011年10月20日23:36 Yukihiro Matsumoto <matz / ruby-lang.org>:
>> んじゃ、それでいいじゃん。私も別に [ruby-dev:44636] は私の意
>> 図を反映してないなんて言うつもりはないです。
> 
> [ruby-dev:44636]++
> 官僚主義になりたい訳ではないですが、1.9のバージョニングがいまいち窮屈だった感じが
> するので今のうちに予防線を張っておきたい所です。
> 
> この位の目安があった方がC拡張使っているgem作者もTEENY上がる時にコンパイルし直しが
> 必要かもしれないとか分かりやすくてよいと思います。
> 
> ABI互換をうたうったのは管理の面でも機能追加の面でも足を引っ張って結果的にはそんなによくなかった。

実は、これでも 1.9.1 以降は 1.8 時代よりも潜在的な ABI 互換性要求はゆるくなっているのですよ。
API VERSION という概念を導入して、3 桁にしたのはいざというときに壊すためなのですから。

> RUBY_VERSIONに時間を取られるのもいまいちなのは同意なので、
> [ruby-dev:44636]が共通認識になると嬉しい。
>
> 所でrelease planのスレッドでこんな事を話しているので
> 違和感があるのかもしれません。
> 2.0のイニシャルリリースには直接関係ない事なのでスレッドを分けるべきでしょうか。

わたしは字面の話では無く、いつどこまで互換性を壊すかについて話しているつもりです。
また、このスレは 2.0.0 だけではなくその後の話も意図していたので、
分ける必要は無いでしょう。

-- 
NARUSE, Yui  <naruse / airemix.jp>

44672 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-23 01:30:24 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
まつもと ゆきひろです

まだ2.0はリリースマネージャが必要なレベルになってないと思いま
すが、遠藤さんが立候補しておられることに反対する理由もありま
せん。どうぞ。

そんなことより、個別の機能を開発しようよ。

In message "Re: [ruby-dev:44668] Re: Ruby 2.0 release plan"
    on Fri, 21 Oct 2011 23:27:56 +0900, SASADA Koichi <ko1 / atdot.net> writes:
|
|まつもとさん
|
| ささだです.
|
|(2011/10/21 21:10), Yusuke Endoh wrote:
|> そういうわけで遠藤は 2.0 のリリースマネージャに絶賛立候補中です!
|
| リリースマネージャ(トップ)を決めるといいと思うのですが,いかがでしょ
|うか.もし何か,躊躇されている点があるようでしたら,仰って頂いたほうがい
|いように思います.
|
|# 早くリリースマネージャにリリースプランを宣言して欲しい.
|
|-- 
|// SASADA Koichi at atdot dot net

44673 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-23 01:39:20 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
まつもと ゆきひろです

In message "Re: [ruby-dev:44667] Re: Ruby 2.0 release plan"
    on Fri, 21 Oct 2011 23:27:46 +0900, Urabe Shyouhei <shyouhei / ruby-lang.org> writes:

|将来は、見通せないからこそ、制御しないといけない。そのように信じて
|います。未来予想を確実に当てるには自分で未来を作ればいい。言ってる
|ことは同じです。まつもとさんはどのような未来を考えていますか。今、
|Rubyはたくさんのコミッターがいて、まつもとさんが「じゃあGIL捨てよ
|う」とか「generational incremental parallel garbage collector希望」
|とか「JIT欲しい」とか言えばみんなでそちらに向かって頑張っていける
|じゃないですか。将来は見通せないからといって何もビジョンを示さない
|ことのほうがよほど不誠実だと思いますね。プロジェクトリーダーの態度
|として。

なんで、そう拡大するのかな。私は「バージョンのつけ方について」
将来を見越した対応として、[ruby-dev:44619]以上のものが必要だ
と思わないと言っただけで、上のようなビジョンを示さないと言っ
てるわけではないんですが。っていうか、示してるじゃん。

なんで「バージョンのつけ方について必要以上に細かいルールを今
決めたくない」っていうと、「ビジョンを示さない」ので「不誠実」
とか言われちゃうわけ。

もう、いいよ。勝手にして。

|バージョンが主なのではありません。開発方針が主なのです。それを考え
|ればバージョン計画は出てくるし、開発も進む。開発が先にくるのは、た
|だのカオスです。

「バージョンによって示される開発方針が主」ということにしたい
のですね。それは私とは考えが違いますね。私は個別の案件を開発
したいです。

44674 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-23 01:41:23 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
まつもと ゆきひろです

In message "Re: [ruby-dev:44666] Re: Ruby 2.0 release plan"
    on Fri, 21 Oct 2011 21:13:02 +0900, Yusuke Endoh <mame / tsg.ne.jp> writes:

|まつもとさん、[ruby-dev:44610] はどう思います?

ABIの互換性を維持を保証しようとするとコストが高すぎると思いま
す。ほんの些細な違いでもABI互換性は崩れちゃうわけで。という
意味で、TEENYだろうがABIは変化する(かもしれない)というルール
で良いと思います。ディスクの節約とか気にする時代じゃないし。

44675 Urabe Shyouhei <shyouhei ruby-lang.org> (2011-10-23 02:18:14 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
On 10/23/2011 01:39 AM, Yukihiro Matsumoto wrote:
> もう、いいよ。勝手にして。

これ以上は対話にならなそうなので、残念です、とだけ申し上げておきます。

44676 Yusuke Endoh <mame tsg.ne.jp> (2011-10-23 13:52:39 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
遠藤です。

2011年10月23日1:30 Yukihiro Matsumoto <matz / ruby-lang.org>:
> まだ2.0はリリースマネージャが必要なレベルになってないと思いま
> すが、遠藤さんが立候補しておられることに反対する理由もありま
> せん。どうぞ。

おお。ありがとうございます。
まあ、今できることってスケジュールの仮決めくらいですよね。


では、粗いスケジュールとして、

  2012 年  8 月 big feature freeze
    ([ruby-core:39810] にあるような大きな新機能の採否決定と、
     大まかな仕様を固める)
  2012 年 10 月 feature freeze
    (実装状況を鑑みて、細かい機能まで含めて採否を決める)
  2013 年  2 月 release

くらいに考えておきましょうか。
あとで英語でアナウンス (+意見あれば募集) しときます。

# 成瀬さんの案は feature freeze から release まで期間が
# 短すぎると思った。



> そんなことより、個別の機能を開発しようよ。

全く同感です。
キーワード引数のコーナーケース考えるの楽しいです。



あと、まつもとさんがちょくちょくおっしゃってますが、基本的に
2.0 で 100% compatible を目指すことは今のところかなり強い
方針なんですよね。
つまり $SAFE 削除 (#5455) なんかは採用の可能性がかなり少ない。

-- 
Yusuke Endoh <mame / tsg.ne.jp>

44678 Masaya TARUI <tarui prx.jp> (2011-10-23 14:16:40 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
2011年10月23日13:52 Yusuke Endoh <mame / tsg.ne.jp>:
>
> あと、まつもとさんがちょくちょくおっしゃってますが、基本的に
> 2.0 で 100% compatible を目指すことは今のところかなり強い
> 方針なんですよね。
> つまり $SAFE 削除 (#5455) なんかは採用の可能性がかなり少ない。

100% compatibleってのは要はJIS規格(+ISO)に適合している事を条件としていると
捉えているんですがあってるでしょうか?
またこれは絶対条件ですか?

-- 
樽家昌也(Masaya TARUI)
No Tool,No Life.

44679 Yusuke Endoh <mame tsg.ne.jp> (2011-10-23 14:33:53 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
遠藤です。

2011年10月23日14:16 Masaya TARUI <tarui / prx.jp>:
> 2011年10月23日13:52 Yusuke Endoh <mame / tsg.ne.jp>:
>>
>> あと、まつもとさんがちょくちょくおっしゃってますが、基本的に
>> 2.0 で 100% compatible を目指すことは今のところかなり強い
>> 方針なんですよね。
>> つまり $SAFE 削除 (#5455) なんかは採用の可能性がかなり少ない。
>
> 100% compatibleってのは要はJIS規格(+ISO)に適合している事を条件としていると
> 捉えているんですがあってるでしょうか?
> またこれは絶対条件ですか?


個人的な意見ですが。

影響が大きそうな機能は原則として消さない、今までのコードの意味が
変わるような変更は原則として入れない、くらいじゃないですかね。
でもまあ、既存コードでもへんちくりんなのやひどく推奨されない書き
方まで気にするかは、個別に検討?

絶対条件かどうかも一概に決められるとは思えず、問題ごとに必要性と
影響度を議論して決めていく感じかと思います。

-- 
Yusuke Endoh <mame / tsg.ne.jp>

44681 Masaya TARUI <tarui prx.jp> (2011-10-23 15:08:23 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
2011年10月23日14:33 Yusuke Endoh <mame / tsg.ne.jp>:
> 遠藤です。
>
> 2011年10月23日14:16 Masaya TARUI <tarui / prx.jp>:
>> 2011年10月23日13:52 Yusuke Endoh <mame / tsg.ne.jp>:
>>>
>>> あと、まつもとさんがちょくちょくおっしゃってますが、基本的に
>>> 2.0 で 100% compatible を目指すことは今のところかなり強い
>>> 方針なんですよね。
>>> つまり $SAFE 削除 (#5455) なんかは採用の可能性がかなり少ない。
>>
>> 100% compatibleってのは要はJIS規格(+ISO)に適合している事を条件としていると
>> 捉えているんですがあってるでしょうか?
>> またこれは絶対条件ですか?
>
>
> 個人的な意見ですが。
>
> 影響が大きそうな機能は原則として消さない、今までのコードの意味が
> 変わるような変更は原則として入れない、くらいじゃないですかね。
> でもまあ、既存コードでもへんちくりんなのやひどく推奨されない書き
> 方まで気にするかは、個別に検討?
>
> 絶対条件かどうかも一概に決められるとは思えず、問題ごとに必要性と
> 影響度を議論して決めていく感じかと思います。

そうですね、ちょっと気がせいてしまってました。
今から絶対的な基準を求めるとか柔軟性を失ってしまい良くないですね。
失礼しました。

-- 
樽家昌也(Masaya TARUI)
No Tool,No Life.

44682 Ayumu AIZAWA <ayumu.aizawa gmail.com> (2011-10-23 15:16:15 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
 с
> > まだ2.0はリリースマネージャが必要なレベルになってないと思いま
> > すが、遠藤さんが立候補しておられることに反対する理由もありま
> > せん。どうぞ。
>  
> おお。ありがとうございます。
> まあ、今できることってスケジュールの仮決めくらいですよね。
>  
遠藤さん、リリースマネジャー就任おめでとうございます!

ところで、松田さんのコミッター就任時に、標準ライブラリのgem化という
テーマも2.xで取り組んでいくものとして考えられているとおもっているのですが、
あわせて標準添付ライブラリの整理についても議論していきたいです。

コアチームでメンテナーが不在のものや、利用者が少なさそうなモノについては、
別途gemで配布するようにしてリリースパッケージからは除外していく方向にして
いきたいと思っています。

----
Ayumu AZIAWA


44686 Yusuke Endoh <mame tsg.ne.jp> (2011-10-23 19:52:33 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
遠藤です。

2011年10月23日15:16 Ayumu AIZAWA <ayumu.aizawa / gmail.com>:
> 遠藤さん、リリースマネジャー就任おめでとうございます!

どうもありがとうございます。


> ところで、松田さんのコミッター就任時に、標準ライブラリのgem化という
> テーマも2.xで取り組んでいくものとして考えられているとおもっているのですが、
> あわせて標準添付ライブラリの整理についても議論していきたいです。
>
> コアチームでメンテナーが不在のものや、利用者が少なさそうなモノについては、
> 別途gemで配布するようにしてリリースパッケージからは除外していく方向にして
> いきたいと思っています。

松田さんがコミッタになった経緯を知りませんが、そういう目的
があるんですかね。


gem 化については [ruby-core:32156] のスレッドで非常に議論
されています。
具体的なアプローチがいくつかあること (どこで開発するかとか、
どうやって gem 化するかとか) 、それぞれのアプローチごとに
メリット・デメリットがちょっとずつ変わってくるようです。

また、制約 (テストを動かすために必要なライブラリを外して
よいか?) やリソース (自動化できるが、誰がやるのか?) を
無視するわけにもいきません。

まずは当該スレッドを整理して、それを踏まえた上で提案をする
ことが必要だと思います。


個人的な印象でいうと stdlib の gem 化には賛成で、
([ruby-core:26388] とか提案して総叩きにあったこともある)

実は [ruby-core:32156] のスレッドの要約に挑戦したことも
あるのですが、

http://redmine.ruby-lang.org/projects/ruby-trunk/wiki/GemifyingStdlibJa

整理が足らないのか、結論が全く見えてこない感じです。

-- 
Yusuke Endoh <mame / tsg.ne.jp>

44652 KOSAKI Motohiro <kosaki.motohiro jp.fujitsu.com> (2011-10-21 00:27:35 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
On 10/20/2011 12:36 AM, Yukihiro Matsumoto wrote:
> まつもと ゆきひろです
> 
> In message "Re: [ruby-dev:44631] Re: Ruby 2.0 release plan"
>     on Thu, 20 Oct 2011 03:31:40 +0900, Urabe Shyouhei <shyouhei / ruby-lang.org> writes:
> 
> |たとえば2.0の次のバージョン番号はどうしますか?
> 
> えーと、[ruby-dev:44619] の基準でなんの不満が?
> 
> |厳格な運用を求めているわけではありませんので、2.1を出すと
> |言っておいて出てみたら3.0だったとかでも全然構いませんが、
> |しかし方針を共有しておかないと2.0の後は一挙にカオスになっ
> |てしまうでしょう。現在の1.8.8のように。
> 
> よくわかんないです。私が繰り返し出してる基準や方針で不満なら、
> どう不満で、どうして欲しいのか明言してください。私が何の方針
> も出してないかのような物言いは不愉快です。
> 
> # モヒカンモード

どこにスレッドをつなげるか迷いましたが、とりあえずここに。

まず、当初のなるせさん案だと「後方互換性」の定義が必要だとおもいます。
いままでのような「だいたい互換」は後方互換か?後方互換でなくなるのはどういう基準か?
ブランチメンテなが神なら全部コードを読んだ上で適切に判断できるのでしょうが
僕はブランチメンテなの負荷が増える運用は反対なので、コアデバロッパみんなに
ある種のゆるい共通認識があり、コミットした本人から自発的に
「僕がいれたrXXXXは後方互換性を破ってるから次のリリースはバージョンあげてください」と
申告されるのが望ましい。

一方まつもとさんの基準だと、コミット内容に関係なく常にTEENYがあがるので、ブランチメンテナの
負荷が増えないという意味で僕に異論はありません。


44622 Yusuke Endoh <mame tsg.ne.jp> (2011-10-19 00:16:10 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
遠藤です。

2011年10月18日23:16 KOSAKI Motohiro <kosaki.motohiro / gmail.com>:
>>>> MAJOR: C・Ruby ソースレベルの後方互換性を切るときに上げる
>>>>
>>>> がいいと思います。
>>>
>>> MINOR では切らないんですかね。
>>
>> 切るんですかね?


↓の話に対して↑がなぜ引用されてるのか文脈がわかりませんでした。


> いままでも、実害なさそうなABI非互換は色々と入っていたし、
> セキュリティ問題とか出たらABI言ってられない状況も出てくるでしょう。
>
> ABI100%互換を決めた瞬間に、セキュリティ問題が報告されてCインターフェースが変わるたびにメジャー番号があがることになって、ちょっと好ましくないかなあ。セキュリティ問題があったことなんて、あんまり大々的に宣伝するものでもないし


要するにどうしようという意見なんですかね?



というか、なんでバージョン規則を変えたいんでしたっけ。
今まで通り、matz の言うとおり [ruby-dev:44619] でいいと思います。

[ruby-dev:44604] で議論すべきところは他にいっぱいあるような。

-- 
Yusuke Endoh <mame / tsg.ne.jp>

44624 Yusuke Endoh <mame tsg.ne.jp> (2011-10-19 01:14:15 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
遠藤です。

2011年10月19日0:35 KOSAKI Motohiro <kosaki.motohiro / gmail.com>:
> 今まで通り、MINORでもAPI/ABIは切れる。

たぶん、互換性の定義が違うんだと思いますが、今までは MINOR では
API/ABI は切れていなかった、という認識です。

「実害なさそうなABI非互換」は互換のうち。何が「実害なさそう」かは
明文化されてないですが、定義の話には立ち入りたくないですね。


> 1.9.3での非公開(のつもりの)APIを明示的にunexportにしたのだって、厳密に言えば非互換でしょう。

ドキュメントがない関数がどうなろうと「実害なさそうな非互換」だと
思います。

厳密な話なら、新しい Ruby メソッドを定義するだけで、かつては
NoMethodError が投げられていた挙動が変わるわけなので非互換、と
なるんですかね。この辺は大人の対応が求められていると思います。


> わたしは逆になぜmameさんがMINORで互換性が切れることにセンシティブなのかが、
> あまり理解できませんでした。

むしろ逆で、今まで以上に ABI 互換性に気を使わなくていいように
しよう、という趣旨のつもりです。

ソースレベルの互換性は今まで程度には保証してほしいと思いますが、
仕様バグによるセキュリティ問題でやむを得ず API 変える程度では、
原理主義的に MAJOR バージョンアップする必要はないと思います。

-- 
Yusuke Endoh <mame / tsg.ne.jp>

44623 KOSAKI Motohiro <kosaki.motohiro gmail.com> (2011-10-19 00:35:18 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
2011年10月18日11:16 Yusuke Endoh <mame / tsg.ne.jp>:
> 遠藤です。
>
> 2011年10月18日23:16 KOSAKI Motohiro <kosaki.motohiro / gmail.com>:
>>>>> MAJOR: C・Ruby ソースレベルの後方互換性を切るときに上げる
>>>>>
>>>>> がいいと思います。
>>>>
>>>> MINOR では切らないんですかね。
>>>
>>> 切るんですかね?
>
>
> ↓の話に対して↑がなぜ引用されてるのか文脈がわかりませんでした。
>
>
>> いままでも、実害なさそうなABI非互換は色々と入っていたし、
>> セキュリティ問題とか出たらABI言ってられない状況も出てくるでしょう。
>>
>> ABI100%互換を決めた瞬間に、セキュリティ問題が報告されてCインターフェースが変わるたびにメジャー番号があがることになって、ちょっと好ましくないかなあ。セキュリティ問題があったことなんて、あんまり大々的に宣伝するものでもないし
>
>
> 要するにどうしようという意見なんですかね?

今まで通り、MINORでもAPI/ABIは切れる。守れる可能性がないから、切る切らないの
議論は無意味。影響が大きそうな切れ方をするときはMAJORがあがる。
これは周知のためであって、それ以上でもそれ以下でもない。

1.9.3での非公開(のつもりの)APIを明示的にunexportにしたのだって、厳密に言えば非互換でしょう。
実際壊れたgemはあるんだし。でも、それを壊さないことは約束するのは不可能。
非公開ヘッダをコピーして、勝手に内部構造体いじってるgemとかあるので、どれだけ気をつけても
1bitでも変えたら壊れるときは壊れる。

要約すると、API/ABIを切る切らないの話は不毛です。が趣旨

わたしは逆になぜmameさんがMINORで互換性が切れることにセンシティブなのかが、
あまり理解できませんでした。


> というか、なんでバージョン規則を変えたいんでしたっけ。
> 今まで通り、matz の言うとおり [ruby-dev:44619] でいいと思います。
>
> [ruby-dev:44604] で議論すべきところは他にいっぱいあるような。

44687 Yukihiro Matsumoto <matz ruby-lang.org> (2011-10-24 09:38:53 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
まつもと ゆきひろです

In message "Re: [ruby-dev:44686] Re: Ruby 2.0 release plan"
    on Sun, 23 Oct 2011 19:52:33 +0900, Yusuke Endoh <mame / tsg.ne.jp> writes:

|> コアチームでメンテナーが不在のものや、利用者が少なさそうなモノについては、
|> 別途gemで配布するようにしてリリースパッケージからは除外していく方向にして
|> いきたいと思っています。
|
|松田さんがコミッタになった経緯を知りませんが、そういう目的
|があるんですかね。

はい、松田さんにはgemについての知見を活かしてくださいという
ことでスカウトしました。あと、Railsとの関係強化もお願いした
いところです。現状、Aaronだけに頼り切りなんで。

44689 Hiroshi Nakamura <nahi ruby-lang.org> (2011-10-24 17:15:17 +0900) Re: Ruby 2.0 release plan

[Translation not available]
Add translation
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/23/2011 07:52 PM, Yusuke Endoh wrote:
> gem 化については [ruby-core:32156] のスレッドで非常に議論 されています。 具体的なアプローチがいくつかあること
> (どこで開発するかとか、 どうやって gem 化するかとか) 、それぞれのアプローチごとに メリット・デメリットがちょっとずつ変わって
> くるようです。
> 
> また、制約 (テストを動かすために必要なライブラリを外して よいか?) やリソース (自動化できるが、誰がやるのか?) を 無視するわ
> けにもいきません。
> 
> まずは当該スレッドを整理して、それを踏まえた上で提案をする ことが必要だと思います。

RubyKaigi2011で、Aaronの提案を元に私がネゴった内容に基づく提案を、
https://redmine.ruby-lang.org/projects/ruby/wiki/StdlibGem
にまとめています。RubyConfの前あたりから、tenderlove、drnicと共に、提
案範囲、実現可能性、やらなきゃいけないことのリストアップをしてたんです
が、そろそろチケット化できる予定です。

[ruby-core:32156]の議論の内容は概ねカバー、というか、現時点で実現が無
理だろう内容は提案のスコープから外し、2.0向けに最低限のgem化を行う提案
です。

> 実は [ruby-core:32156] のスレッドの要約に挑戦したことも あるのですが、
> 
> http://redmine.ruby-lang.org/projects/ruby-trunk/wiki/GemifyingStdlibJa
>
>  整理が足らないのか、結論が全く見えてこない感じです。

おお、この存在は気づいてませんでした。。。英語版があれば楽だったかなあ。

この提案から言うと、バリエーションとしてはV-A-1 + V-B-1、V-Cはこれか
ら、V-Dはスコープ外、です。厳密に言うと、V-A-1ともちょっと違いそうですが、
詳細は提案後に議論させてください。

以上です。
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJOpR6JAAoJEC7N6P3yLbI2/7AIAJTKDWQIP+tXUV8FpDt8U0cO
CrrPYB3k3N2r4nvAANBJBzQX79+cI1MXKPsMUNG7Oprw7wqPkpgUKmzJrG/sWKer
v3VDfNm2RvDreD7U+S4LtoNbUgbfFFbnyalXGE/TrgAu5KH94oFVCsAH6OCMz2UD
FzR2zq+o2wpxYEjyHpvqqcZaxgO3Lpr5+sAmEhpZu9KWAcpOAxhc+rjwOgx8cFIh
qKH60QDz2PiImIUZw7M3FJvdT2yuYWccpDS1y18aaGarpH6oHvA4Bj3vmoQ/M74c
BKGkHtVVuudduAF8PDgbrNp7poP/Ha0DbmqVc4GO1JkbCH4FZZir7Qe26x7zd34=
=e8+t
-----END PGP SIGNATURE-----

Back