https://redmine.ruby-lang.org/
https://redmine.ruby-lang.org/favicon.ico?1711330511
2013-08-30T22:06:32Z
Ruby Issue Tracking System
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=41429
2013-08-30T22:06:32Z
knu (Akinori MUSHA)
knu@ruby-lang.org
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/41429/diff?detail_id=30040">diff</a>)</li></ul>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=41430
2013-08-30T23:26:23Z
nobu (Nobuyoshi Nakada)
nobu@ruby-lang.org
<ul><li><strong>Assignee</strong> changed from <i>nobu (Nobuyoshi Nakada)</i> to <i>knu (Akinori MUSHA)</i></li></ul>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=41438
2013-08-31T02:53:28Z
Anonymous
<ul><li><strong>File</strong> <a href="/attachments/3923">noname</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3923/noname">noname</a> added</li></ul><p>At Fri, 30 Aug 2013 21:49:34 +0900,<br>
I wrote:</p>
<blockquote>
<p>misc <a class="issue tracker-5 status-5 priority-4 priority-default closed" title="Misc: Introducing a semantic versioning scheme and branching policy (Closed)" href="https://redmine.ruby-lang.org/issues/8835">#8835</a>: Introducing a semantic versioning scheme and branching policy<br>
<a href="https://bugs.ruby-lang.org/issues/8835" class="external">https://bugs.ruby-lang.org/issues/8835</a></p>
</blockquote>
<p> DevelopersMeeting20130831Japanでのプレゼンのために、<a href="/issues/8835">[ruby-core:56878]</a><br>
[misc <a class="issue tracker-5 status-5 priority-4 priority-default closed" title="Misc: Introducing a semantic versioning scheme and branching policy (Closed)" href="https://redmine.ruby-lang.org/issues/8835">#8835</a>] を日本語で補足します。</p>
<p> 直接的なきっかけは [ruby-list:49555] のスレッドです。元の問題自体は、<br>
RubyGemsを直すべきだと思います。ただ、1.8, 1.9, 2.0と、バージョンの運用<br>
状況が毎回なんとなしに変わってきており、PATCHLEVELまであるRUBY_VERSION<br>
がAPI互換性については多くを示さず、RUBY_API_VERSIONが別途あるというのは<br>
ちょっといただけない状況だと思いました。</p>
<p> そこで、この提案は [MAJOR & MINOR, TEENY, PATCHLEVEL] がSemantic<br>
Versioning (<a href="http://semver.org/)%E3%81%AB%E6%B2%BF%E3%81%86%E3%82%88%E3%81%86%E3%81%AB%E5%86%8D%E5%AE%9A%E7%BE%A9%E3%81%97%E3%82%88%E3%81%86%E3%81%A8%E3%81%84%E3%81%86%E3%82%82%E3%81%AE%E3%81%A7%E3%81%99%E3%80%82" class="external">http://semver.org/)に沿うように再定義しようというものです。</a><br>
Ruby自体をAPI互換性を考慮したバージョン体系にすることによって、1.9で導<br>
入されたもののあまり有意義に運用されなかったRUBY_API_VERSIONと統一し、<br>
両者の不一致から来る潜在的なユーザの混乱および互換性に関する懸念の解消<br>
を図ります。</p>
<p> 開発陣におけるABI互換性についての意識は高まっており、試験的ながら<br>
Ruby-CIにもABIチェックが入っているので、Semantic Versioningを運用してい<br>
くことが現実的に可能だと思います。</p>
<p> TEENYが9までしか使えないという縛りはありますが、MAJOR.MINOR.0のリリー<br>
ス後に、APIを追加・拡張したリリースを9回も行う必要は薄く、いつでも追加・<br>
拡張をやめてバグ修正のみのフェーズに移行できるので、枯渇を気にする必要<br>
はないでしょう。</p>
<p> 機能追加を行った次のTEENYリリースを準備中に、もしセキュリティ等に関す<br>
るクリティカルな修正が必要になった場合は、それ以外の修正も入った次の<br>
TEENYリリース準備ブランチの安定を確認する必要はなく、現行のTEENYリリー<br>
スブランチからすぐにPATCHLEVELリリースを行えます。つまり、PATCHLEVELは<br>
主にセキュリティ修正レベルという意味づけになり、リリースする側の手間が<br>
減ることはもちろん、安定性や互換性を重視するベンダーやユーザのニーズに<br>
応えるものです。</p>
<p> なお、1.8系列および1.9系列ではTEENYの違いでもABI/API非互換があったの<br>
で各TEENYごとにそれぞれ保守を続ける必要が生じていましたが、このスキーム<br>
では、新しいTEENYが出たら上位互換性を盾に1つ前のTEENYの保守をすぐに打ち<br>
切れます。ただ、継続を望むベンダーがいれば、古いTEENYのブランチを保守し<br>
てもらうのもありでしょう。(coreチームとしてのリリースは行わないでしょ<br>
うが)</p>
<p> ブランチの作成・運用手順についても記述しています。これはFreeBSDや<br>
NetBSDに倣ったもので、特に独自な点はありません。</p>
<p>--<br>
Akinori MUSHA / <a href="https://akinori.org/" class="external">https://akinori.org/</a></p>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=41445
2013-08-31T08:53:10Z
kosaki (Motohiro KOSAKI)
kosaki.motohiro@gmail.com
<ul></ul><p>2013/8/30 Akinori MUSHA <a href="mailto:knu@idaemons.org" class="email">knu@idaemons.org</a>:</p>
<blockquote>
<p>At Fri, 30 Aug 2013 21:49:34 +0900,<br>
I wrote:</p>
<blockquote>
<p>misc <a class="issue tracker-5 status-5 priority-4 priority-default closed" title="Misc: Introducing a semantic versioning scheme and branching policy (Closed)" href="https://redmine.ruby-lang.org/issues/8835">#8835</a>: Introducing a semantic versioning scheme and branching policy<br>
<a href="https://bugs.ruby-lang.org/issues/8835" class="external">https://bugs.ruby-lang.org/issues/8835</a></p>
</blockquote>
<p> DevelopersMeeting20130831Japanでのプレゼンのために、<a href="/issues/8835">[ruby-core:56878]</a><br>
[misc <a class="issue tracker-5 status-5 priority-4 priority-default closed" title="Misc: Introducing a semantic versioning scheme and branching policy (Closed)" href="https://redmine.ruby-lang.org/issues/8835">#8835</a>] を日本語で補足します。</p>
<p> 直接的なきっかけは [ruby-list:49555] のスレッドです。元の問題自体は、<br>
RubyGemsを直すべきだと思います。ただ、1.8, 1.9, 2.0と、バージョンの運用<br>
状況が毎回なんとなしに変わってきており、PATCHLEVELまであるRUBY_VERSION<br>
がAPI互換性については多くを示さず、RUBY_API_VERSIONが別途あるというのは<br>
ちょっといただけない状況だと思いました。</p>
<p> そこで、この提案は [MAJOR & MINOR, TEENY, PATCHLEVEL] がSemantic<br>
Versioning (<a href="http://semver.org/)%E3%81%AB%E6%B2%BF%E3%81%86%E3%82%88%E3%81%86%E3%81%AB%E5%86%8D%E5%AE%9A%E7%BE%A9%E3%81%97%E3%82%88%E3%81%86%E3%81%A8%E3%81%84%E3%81%86%E3%82%82%E3%81%AE%E3%81%A7%E3%81%99%E3%80%82" class="external">http://semver.org/)に沿うように再定義しようというものです。</a><br>
Ruby自体をAPI互換性を考慮したバージョン体系にすることによって、1.9で導<br>
入されたもののあまり有意義に運用されなかったRUBY_API_VERSIONと統一し、<br>
両者の不一致から来る潜在的なユーザの混乱および互換性に関する懸念の解消<br>
を図ります。</p>
<p> 開発陣におけるABI互換性についての意識は高まっており、試験的ながら<br>
Ruby-CIにもABIチェックが入っているので、Semantic Versioningを運用してい<br>
くことが現実的に可能だと思います。</p>
<p> TEENYが9までしか使えないという縛りはありますが、MAJOR.MINOR.0のリリー<br>
ス後に、APIを追加・拡張したリリースを9回も行う必要は薄く、いつでも追加・<br>
拡張をやめてバグ修正のみのフェーズに移行できるので、枯渇を気にする必要<br>
はないでしょう。</p>
</blockquote>
<p>えっ。<br>
いまのパッチレベルリリースはほとんどのケースでシンボルの追加があると思いますが。</p>
<p>あと、Rubyのクラスは「開いている」ので、どんなバグフィックスであってもあやしげなモンキーパッチャーさんはぎゃっというリスクはあるわけで、このルールだとパッチレベルだけですむケースがほぼ無くなるんじゃないかなあ。</p>
<p>開発陣におけるABI互換性についての意識は高まっているという認識にも懐疑的で、意識している人はしているししていない人は全然していないので、メンテナーの負荷を減らすにはコミッターの善意だけではだめでツールの助けがいるというのが<br>
ABI checker導入時のバックグラウンドモチベーションとしてありました。</p>
<p>実際問題として1.9.3とかp0と最新では結構な非互換が検出されてます。</p>
<p>というわけで、カウンタープロポーサルとして、TEENYを0固定にして、パッチレベルはsymbol削減方向の非互換はしないが、symbol追加の非互換はあり(rb_,<br>
ruby_ prefixの関数を自モジュールにつかう拡張が悪い)というRubyオレオレルールを継続することを提案します。</p>
<p>ついでに、いまはRubyレベルの非互換について、一切ツール支援がない状況ですので、こちらについても対策に関する意見を広く募集したいところです。</p>
<blockquote>
<p> 機能追加を行った次のTEENYリリースを準備中に、もしセキュリティ等に関す<br>
るクリティカルな修正が必要になった場合は、それ以外の修正も入った次の<br>
TEENYリリース準備ブランチの安定を確認する必要はなく、現行のTEENYリリー<br>
スブランチからすぐにPATCHLEVELリリースを行えます。つまり、PATCHLEVELは<br>
主にセキュリティ修正レベルという意味づけになり、リリースする側の手間が<br>
減ることはもちろん、安定性や互換性を重視するベンダーやユーザのニーズに<br>
応えるものです。</p>
</blockquote>
<p>モチベーションは理解できます。少なくともパッチレベルでの非互換はなくしたいですね。</p>
<p>実際の運用として、p0の後の最初の2つぐらいのパッチレベルリリースは非互換ありでも許されてきた経緯があり(どうせp0なんか使うやついないという判断により)、どのタイミングで非互換なしになるのかはメンテナーに任されていた部分が大だったと思います。<br>
これが、当初の2−3回のリリースはTEENYあげる。(Rubyコミュニティが99.9%のユーザが被害を受けないと考えるような)小さな非互換もありうる。それ以降はパッチレベルでsymbol<br>
削除方向の非互換はなし。とかだったら分かりやすいし、ツール支援もしやすいので賛成しやすいですね。</p>
<p>ではでは。</p>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=41447
2013-08-31T09:53:17Z
nobu (Nobuyoshi Nakada)
nobu@ruby-lang.org
<ul></ul><p>(13/08/31 8:49), KOSAKI Motohiro wrote:</p>
<blockquote>
<p>というわけで、カウンタープロポーサルとして、TEENYを0固定にして、パッチレベルはsymbol削減方向の非互換はしないが、symbol追加の非互換はあり(rb_,<br>
ruby_ prefixの関数を自モジュールにつかう拡張が悪い)というRubyオレオレルールを継続することを提案します。</p>
</blockquote>
<p>固定だったら無意味なので、パッチレベルを廃止してTEENYを上げてけばいいんじゃないですかね。<br>
バージョンを比較したければGem::Version使えってことで。</p>
<p>--<br>
--- 僕の前にBugはない。<br>
--- 僕の後ろにBugはできる。<br>
中田 伸悦</p>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=41449
2013-08-31T11:23:18Z
kosaki (Motohiro KOSAKI)
kosaki.motohiro@gmail.com
<ul></ul><blockquote>
<blockquote>
<p>というわけで、カウンタープロポーサルとして、TEENYを0固定にして、パッチレベルはsymbol削減方向の非互換はしないが、symbol追加の非互換はあり(rb_,<br>
ruby_ prefixの関数を自モジュールにつかう拡張が悪い)というRubyオレオレルールを継続することを提案します。</p>
</blockquote>
<p>固定だったら無意味なので、パッチレベルを廃止してTEENYを上げてけばいいんじゃないですかね。<br>
バージョンを比較したければGem::Version使えってことで。</p>
</blockquote>
<p>既存のコードを動かなくさせるメリットが見つけられませんでした。美しさにこだわるところじゃないと思う</p>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=41454
2013-08-31T12:23:28Z
Anonymous
<ul><li><strong>File</strong> <a href="/attachments/3932">noname</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3932/noname">noname</a> added</li></ul><p>At Fri, 30 Aug 2013 19:49:59 -0400,<br>
KOSAKI Motohiro wrote:</p>
<blockquote>
<p>えっ。<br>
いまのパッチレベルリリースはほとんどのケースでシンボルの追加があると思いますが。</p>
</blockquote>
<p>はい。意味を変えるという提案なので。仮に 2.0 系列に新しいスキームを適用<br>
していたとすると、パッチレベルリリースは半年ちょっと経ちましたがまだ2回<br>
だけなので現在 2.0.2 になっており、仮に年内にあと2回くらい機能追加を含<br>
むリリースを出したとして 2.0.4、そこで 2.1.0 が出て、前方互換性を改善す<br>
る機能追加や拡張を行いましょうというときにあと5回変身を残している感じで<br>
す。十分ではないでしょうか。(後方非互換性については後述)</p>
<blockquote>
<p>あと、Rubyのクラスは「開いている」ので、どんなバグフィックスであってもあやしげなモンキーパッチャーさんはぎゃっというリスクはあるわけで、このルールだとパッチレベルだけですむケースがほぼ無くなるんじゃないかなあ。</p>
</blockquote>
<p>パッチレベルだけで済まない変更を加えた上でのリリースの余地が9回あれば、<br>
現在のリリースサイクルを見るに十分ではないかというのが主旨です。</p>
<blockquote>
<p>開発陣におけるABI互換性についての意識は高まっているという認識にも懐疑的で、意識している人はしているししていない人は全然していないので、メンテナーの負荷を減らすにはコミッターの善意だけではだめでツールの助けがいるというのが<br>
ABI checker導入時のバックグラウンドモチベーションとしてありました。</p>
</blockquote>
<p>そもそも現在API versionというのが実は何の役割も果たしていない(1.9でも<br>
2.0でもTEENYすら上がっていないし後方互換性も保たれていない)状況ですが、<br>
少なくとも追加や拡張があるので上げるべき、削除や変更があるのでバックポー<br>
ト不可、という判断がツールの支援である程度デジタルにできるようになりま<br>
した。</p>
<blockquote>
<p>実際問題として1.9.3とかp0と最新では結構な非互換が検出されてます。</p>
<p>というわけで、カウンタープロポーサルとして、TEENYを0固定にして、パッチレベルはsymbol削減方向の非互換はしないが、symbol追加の非互換はあり(rb_,<br>
ruby_ prefixの関数を自モジュールにつかう拡張が悪い)というRubyオレオレルールを継続することを提案します。</p>
</blockquote>
<p>それだと、追加されたシンボルに依存したバイナリ物を配布するときにバージョ<br>
ン番号でチェックできないのが困ります。ビルド時や実行時はextconf.rb や<br>
respond_to? 等々でチェックもできますが、RubyGemsを含むパッケージシステ<br>
ムがインストールの際にバージョン番号で比較するしかないというところにニー<br>
ズがあります。</p>
<blockquote>
<p>ついでに、いまはRubyレベルの非互換について、一切ツール支援がない状況ですので、こちらについても対策に関する意見を広く募集したいところです。</p>
</blockquote>
<p>そうですね。そこは課題として認識します。</p>
<blockquote>
<blockquote>
<p> 機能追加を行った次のTEENYリリースを準備中に、もしセキュリティ等に関す<br>
るクリティカルな修正が必要になった場合は、それ以外の修正も入った次の<br>
TEENYリリース準備ブランチの安定を確認する必要はなく、現行のTEENYリリー<br>
スブランチからすぐにPATCHLEVELリリースを行えます。つまり、PATCHLEVELは<br>
主にセキュリティ修正レベルという意味づけになり、リリースする側の手間が<br>
減ることはもちろん、安定性や互換性を重視するベンダーやユーザのニーズに<br>
応えるものです。</p>
</blockquote>
<p>モチベーションは理解できます。少なくともパッチレベルでの非互換はなくしたいですね。</p>
<p>実際の運用として、p0の後の最初の2つぐらいのパッチレベルリリースは非互換ありでも許されてきた経緯があり(どうせp0なんか使うやついないという判断により)、どのタイミングで非互換なしになるのかはメンテナーに任されていた部分が大だったと思います。</p>
</blockquote>
<p>1.9.0 はプレビュー版、 1.9.1 はデベロッパー版みたいな感じでしたね。2.0<br>
系列は、1.9での苦難のleapを果たした直後だけにうまく行きすぎているという<br>
のはあります。</p>
<blockquote>
<p>これが、当初の2−3回のリリースはTEENYあげる。(Rubyコミュニティが99.9%のユーザが被害を受けないと考えるような)小さな非互換もありうる。それ以降はパッチレベルでsymbol<br>
削除方向の非互換はなし。とかだったら分かりやすいし、ツール支援もしやすいので賛成しやすいですね。</p>
</blockquote>
<p>新しいスキームでも TEENY=0 くらいはプレビュー扱いで TEENY=1 で非互換も<br>
あるよ、というのもいいかもしれません。少なくともどこからメンテナンス<br>
フェーズか、非互換はあるか、という指針を内外に示すことが大事。</p>
<p>--<br>
Akinori MUSHA / <a href="https://akinori.org/" class="external">https://akinori.org/</a></p>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=41455
2013-08-31T12:53:17Z
kosaki (Motohiro KOSAKI)
kosaki.motohiro@gmail.com
<ul></ul><blockquote>
<blockquote>
<p>えっ。<br>
いまのパッチレベルリリースはほとんどのケースでシンボルの追加があると思いますが。</p>
</blockquote>
<p>はい。意味を変えるという提案なので。仮に 2.0 系列に新しいスキームを適用<br>
していたとすると、パッチレベルリリースは半年ちょっと経ちましたがまだ2回<br>
だけなので現在 2.0.2 になっており、仮に年内にあと2回くらい機能追加を含<br>
むリリースを出したとして 2.0.4、そこで 2.1.0 が出て、前方互換性を改善す<br>
る機能追加や拡張を行いましょうというときにあと5回変身を残している感じで<br>
す。十分ではないでしょうか。(後方非互換性については後述)</p>
<blockquote>
<p>あと、Rubyのクラスは「開いている」ので、どんなバグフィックスであってもあやしげなモンキーパッチャーさんはぎゃっというリスクはあるわけで、このルールだとパッチレベルだけですむケースがほぼ無くなるんじゃないかなあ。</p>
</blockquote>
<p>パッチレベルだけで済まない変更を加えた上でのリリースの余地が9回あれば、<br>
現在のリリースサイクルを見るに十分ではないかというのが主旨です。</p>
</blockquote>
<p>ちょっと自身がなかったので1.8.7のリリース回数を調べてみたのですがp0と合わせて22回<br>
リリースが行われています。<br>
いくつかはパッチレベルに出来るのでしょうが、9回あれば楽勝というレベルかというと<br>
ちょっと自身が持てませんでした。</p>
<p>前回のメールで書いたとおり、rubyレベルの変更が1つでも入ったらTEENYをbumpしないと<br>
いけない提案に見えるためです。</p>
<p>[ ] ruby-1.8.7-p17.tar.bz2 10-Jun-2008 03:40 3.9M<br>
[ ] ruby-1.8.7-p22.tar.bz2 21-Jun-2008 03:30 3.9M<br>
[ ] ruby-1.8.7-p71.tar.bz2 08-Aug-2008 20:09 3.9M<br>
[ ] ruby-1.8.7-p72.tar.bz2 11-Aug-2008 18:40 3.9M<br>
[ ] ruby-1.8.7-p160.tar.bz2 09-Apr-2009 22:44 3.9M<br>
[ ] ruby-1.8.7-p173.tar.bz2 10-Jun-2009 17:50 4.0M<br>
[ ] ruby-1.8.7-p174.tar.bz2 16-Jun-2009 17:58 4.0M<br>
[ ] ruby-1.8.7-p248.tar.bz2 25-Dec-2009 03:37 4.0M<br>
[ ] ruby-1.8.7-p249.tar.bz2 11-Jan-2010 04:32 4.0M<br>
[ ] ruby-1.8.7-p299.tar.bz2 24-Jun-2010 09:36 4.0M<br>
[ ] ruby-1.8.7-p301.tar.bz2 16-Aug-2010 21:43 4.0M<br>
[ ] ruby-1.8.7-p302.tar.bz2 17-Aug-2010 01:32 4.0M<br>
[ ] ruby-1.8.7-p330.tar.bz2 24-Dec-2010 21:33 4.0M<br>
[ ] ruby-1.8.7-p334.tar.bz2 19-Feb-2011 06:43 4.0M<br>
[ ] ruby-1.8.7-p352.tar.bz2 03-Jul-2011 03:54 4.0M<br>
[ ] ruby-1.8.7-p357.tar.bz2 29-Dec-2011 06:50 4.0M<br>
[ ] ruby-1.8.7-p358.tar.bz2 17-Feb-2012 03:01 4.0M<br>
[ ] ruby-1.8.7-p370.tar.bz2 30-Jun-2012 07:18 4.0M<br>
[ ] ruby-1.8.7-p371.tar.bz2 12-Oct-2012 22:32 4.1M<br>
[ ] ruby-1.8.7-p373.tar.bz2 28-Jun-2013 05:24 4.1M<br>
[ ] ruby-1.8.7-p374.tar.bz2 28-Jun-2013 05:57 4.1M<br>
[ ] ruby-1.8.7.tar.bz2 01-Jun-2008 09:19 3.9M</p>
<blockquote>
<blockquote>
<p>開発陣におけるABI互換性についての意識は高まっているという認識にも懐疑的で、意識している人はしているししていない人は全然していないので、メンテナーの負荷を減らすにはコミッターの善意だけではだめでツールの助けがいるというのが<br>
ABI checker導入時のバックグラウンドモチベーションとしてありました。</p>
</blockquote>
<p>そもそも現在API versionというのが実は何の役割も果たしていない(1.9でも<br>
2.0でもTEENYすら上がっていないし後方互換性も保たれていない)状況ですが、<br>
少なくとも追加や拡張があるので上げるべき、削除や変更があるのでバックポー<br>
ト不可、という判断がツールの支援である程度デジタルにできるようになりま<br>
した。</p>
</blockquote>
<p>そうですね。同意します</p>
<blockquote>
<blockquote>
<p>実際問題として1.9.3とかp0と最新では結構な非互換が検出されてます。</p>
<p>というわけで、カウンタープロポーサルとして、TEENYを0固定にして、パッチレベルはsymbol削減方向の非互換はしないが、symbol追加の非互換はあり(rb_,<br>
ruby_ prefixの関数を自モジュールにつかう拡張が悪い)というRubyオレオレルールを継続することを提案します。</p>
</blockquote>
<p>それだと、追加されたシンボルに依存したバイナリ物を配布するときにバージョ<br>
ン番号でチェックできないのが困ります。ビルド時や実行時はextconf.rb や<br>
respond_to? 等々でチェックもできますが、RubyGemsを含むパッケージシステ<br>
ムがインストールの際にバージョン番号で比較するしかないというところにニー<br>
ズがあります。</p>
</blockquote>
<p>全然知らないのですが、gemはパッチレベルはチェックできないもの?</p>
<blockquote>
<blockquote>
<p>ついでに、いまはRubyレベルの非互換について、一切ツール支援がない状況ですので、こちらについても対策に関する意見を広く募集したいところです。</p>
</blockquote>
<p>そうですね。そこは課題として認識します。</p>
<blockquote>
<blockquote>
<p> 機能追加を行った次のTEENYリリースを準備中に、もしセキュリティ等に関す<br>
るクリティカルな修正が必要になった場合は、それ以外の修正も入った次の<br>
TEENYリリース準備ブランチの安定を確認する必要はなく、現行のTEENYリリー<br>
スブランチからすぐにPATCHLEVELリリースを行えます。つまり、PATCHLEVELは<br>
主にセキュリティ修正レベルという意味づけになり、リリースする側の手間が<br>
減ることはもちろん、安定性や互換性を重視するベンダーやユーザのニーズに<br>
応えるものです。</p>
</blockquote>
<p>モチベーションは理解できます。少なくともパッチレベルでの非互換はなくしたいですね。</p>
<p>実際の運用として、p0の後の最初の2つぐらいのパッチレベルリリースは非互換ありでも許されてきた経緯があり(どうせp0なんか使うやついないという判断により)、どのタイミングで非互換なしになるのかはメンテナーに任されていた部分が大だったと思います。</p>
</blockquote>
<p>1.9.0 はプレビュー版、 1.9.1 はデベロッパー版みたいな感じでしたね。2.0<br>
系列は、1.9での苦難のleapを果たした直後だけにうまく行きすぎているという<br>
のはあります。</p>
<blockquote>
<p>これが、当初の2−3回のリリースはTEENYあげる。(Rubyコミュニティが99.9%のユーザが被害を受けないと考えるような)小さな非互換もありうる。それ以降はパッチレベルでsymbol<br>
削除方向の非互換はなし。とかだったら分かりやすいし、ツール支援もしやすいので賛成しやすいですね。</p>
</blockquote>
<p>新しいスキームでも TEENY=0 くらいはプレビュー扱いで TEENY=1 で非互換も<br>
あるよ、というのもいいかもしれません。少なくともどこからメンテナンス<br>
フェーズか、非互換はあるか、という指針を内外に示すことが大事。</p>
</blockquote>
<p>はい。細かいところで気になるところはありますが、総論としては賛成です。</p>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=41543
2013-09-03T01:24:50Z
naruse (Yui NARUSE)
naruse@airemix.jp
<ul></ul><p>ABI 互換性をどう考え、どう守り、どう示すのかは Ruby 1.9.1 以降幾度となく議論されていた懸案で、<br>
その中で共有されてきたいくつかの前提が、本提案では無視されているように思います。</p>
<p>具体的には、</p>
<ul>
<li>我々はABI後方互換性を保っている気でいる(が、しばしば壊れてしまうことがある) → 事前の人力のアノテーションでは回避出来ないと言うこと</li>
<li>脆弱性が発見されたら生きている全てのブランチでリリースが必要</li>
<li>メンテナンスコストは生きているブランチ数に応じて増える</li>
<li>2年程度は使い続けられるブランチが欲しい</li>
<li>1.9.1-1.9.3 ではABI互換性は保たれたという公式見解 (なぜなら最近まで互換性破壊を指摘する人がいなかったから)</li>
<li>2.0.0 では 1.9.x からの ABI 互換性を破壊したという見解<br>
あたりですか。</li>
</ul>
<p>過去の議論は例えば以下のスレッドがあります。</p>
<ul>
<li><a href="https://blade.ruby-lang.org/ruby-core/19113">[ruby-core:19113]</a></li>
<li><a href="https://blade.ruby-lang.org/ruby-dev/43152">[ruby-dev:43152]</a></li>
<li><a href="https://blade.ruby-lang.org/ruby-dev/36655">[ruby-dev:36655]</a></li>
<li><a href="https://blade.ruby-lang.org/ruby-dev/36889">[ruby-dev:36889]</a></li>
<li><a href="https://blade.ruby-lang.org/ruby-dev/44604">[ruby-dev:44604]</a></li>
</ul>
<p>で、提案は現状をまとめ、あるべき姿を動機と共に示し、差分を提案すべき所、<br>
現状の認識がちょっと違う気がするし、あるべき姿はあるけれど動機が抜けているのでなんかわかりづらいです。<br>
そもそも、このスレって「互換性を守ろう」って話と「互換性を壊そう」って話が混ざってますよね。<br>
開発者会議で akr さんが「shim がやりたいんだよね?」と指摘してらっしゃいましたが、<br>
その辺は互換性を守る話ときちんと分離してください。</p>
<p>kosaki さんの Microsoft のプロダクトライフサイクルっぽい提案はー、どうなんでしょうね。<br>
ツールは別に基準となる patch level を与えればいいだけの話で、<br>
もっぱらマーケティング的な観点で考えるべきもののように感じます。</p>
<p>P.S.<br>
英語のチケットに日本語がぶら下がっていると英語しか読めない人から見て感じが悪いので、<br>
そうしたいときには別に日本語のチケットを作ってそこからぶら下げるようにして下さい。</p>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=41618
2013-09-05T04:23:49Z
steveklabnik (Steve Klabnik)
steve@steveklabnik.com
<ul></ul><blockquote>
<p>英語のチケットに日本語がぶら下がっていると英語しか読めない人から見て感じが悪いので、<br>
そうしたいときには別に日本語のチケットを作ってそこからぶら下げるようにして下さい。</p>
</blockquote>
<p>I only know a very small amount of Japanese, but the Google Translate of your post was very understandable.</p>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=43557
2013-12-10T05:18:11Z
zzak (zzak _)
<ul></ul><p>We have accepted hsbt's proposal: <a href="https://gist.github.com/sorah/7803201" class="external">https://gist.github.com/sorah/7803201</a></p>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=43727
2013-12-18T07:44:40Z
zzak (zzak _)
<ul></ul><p>I have submitted announcement for semantic versioning scheme to ruby-lang.org: <a href="https://github.com/ruby/www.ruby-lang.org/pull/468" class="external">https://github.com/ruby/www.ruby-lang.org/pull/468</a></p>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=44020
2014-01-03T01:57:54Z
vo.x (Vit Ondruch)
v.ondruch@tiscali.cz
<ul></ul><p>Do I understand correctly that patch level won't be anymore part of the released tarball name? E.g. retrofitting semver on Ruby 2.0, the first released bugfix release had been ruby-2.0.0-p195.tar.gz, so with the semver, it would have be ruby-2.0.1.tar.gz</p>
<p>I am asking, since in Fedora, we include the patch level in version, i.e. we had ruby-2.0.0.195 package for Ruby 2.0.0-p195 release. Now we can drop this practice, if I am not mistaken.</p>
<p>Thanks for clarification.</p>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=44025
2014-01-03T04:15:40Z
luislavena (Luis Lavena)
luislavena@gmail.com
<ul></ul><p>vo.x (Vit Ondruch) wrote:</p>
<blockquote>
<p>Do I understand correctly that patch level won't be anymore part of the released tarball name? E.g. retrofitting semver on Ruby 2.0, the first released bugfix release had been ruby-2.0.0-p195.tar.gz, so with the semver, it would have be ruby-2.0.1.tar.gz</p>
</blockquote>
<p>Hello Vit,</p>
<p>Is my understanding that semantic versioning will apply starting from 2.1.0 and not backward applied to 2.0.0</p>
<p>2.0.0 will continue the same version schema it has but Ruby 2.1 will bump TEENY version number on every release.</p>
<p>Patchlevel will still be increased, but that will refer to the number of "patches" it receive between releases.</p>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=44795
2014-01-30T06:17:11Z
hsbt (Hiroshi SHIBATA)
hsbt@ruby-lang.org
<ul><li><strong>Target version</strong> changed from <i>2.1.0</i> to <i>2.2.0</i></li></ul>
Ruby master - Misc #8835: Introducing a semantic versioning scheme and branching policy
https://redmine.ruby-lang.org/issues/8835?journal_id=48300
2014-08-12T03:34:43Z
hsbt (Hiroshi SHIBATA)
hsbt@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>We already applied to use SemVer 'like' versioning after Ruby 2.1.</p>
<p>see also. <a href="https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/" class="external">https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/</a></p>