Misc #8835: Introducing a semantic versioning scheme and branching policy

• Status: Closed
• Assignee: knu (Akinori MUSHA)

[knu (Akinori MUSHA)]

=begin
[This is a presentation for [[ruby:DevelopersMeeting20130831Japan]].]

Ruby's versioning scheme is currently not well defined or well
utilized.

First, RUBY_API_VERSION was introduced in 1.9.1, but has not been
properly maintained since then. There must have been at least a few
ABI incompatible changes (although we tried hard to keep source level
compatibility) and many API additions between 1.9.1 and 1.9.3, but
RUBY_API_VERSION was never bumped.

Secondly, it looks like TEENY version is fixed to zero in the 2.x
series without being used effectively. We often find overlooked
incompatibility or feature bugs after an official release x.y.0, and
would like to fix them in a backward compatible way. I'd suggest we
accept such a situation will happen, and bump TEENY when such a fix
that affects forward compatibility is made. We have up to nine times
of chance for fixing such a situation, and shouldn't be too worried
about running out of digits.

So, here I propose introducing a new versioning scheme as follows,
much with Semantic Versioning (http://semver.org/) in mind:

(1) From 2.1.0 and on, RUBY_API_VERSION shall match RUBY_VERSION.

Giving them different numbers has been a source of confusion, and
introducing this scheme is a way to provide RUBY_VERSION with how to
read API compatibility from the numbers.

(2) MINOR version is incremented when an incompatible API change is
made.

In practice, it is incremented before a change to break
compatibility is actually made.  It is when a relatively significant
amount of change is going to be made, which would break
compatibility, or hurts stability for a certain period of time.

Before making such a change, a new stable branch
ruby_{MAJOR}_{MINOR} is cut off from trunk, and MINOR version is
bumped on trunk.  MAJOR version may be incremented instead,
resetting MINOR to zero.

On the ruby_{MAJOR}_{MINOR} branch, when the time comes for
prereleasing {MAJOR}.{MINOR}.0, a new branch
ruby_{MAJOR}_{MINOR}_0 is cut off from the ruby_{MAJOR}_{MINOR}
branch.

(3) TEENY version is incremented when functionality is added in a
backward-compatible manner.

It happens on ruby_{MAJOR}_{MINOR} branches, where a new branch
ruby_{MAJOR}_{MINOR}_{TEENY} is cut off when it is released,
resetting PATCHLEVEL to zero.

(4) PATCHLEVEL is initialized to zero on each
ruby_{MAJOR}{MINOR}{TEENY} branch where TEENY > 0 on creation,
and incremented every time a change is made on the branch.

On a ruby_{MAJOR}_{MINOR}_0 branch, PATCHLEVEL is kept at -1
during the prerelease period.  It is set to zero when
{MAJOR}.{MINOR}.0 is officially released.

On other branches, it is fixed to -1.

Note that MINOR and TEENY need not be bumped every time an applicable
change is made, but once before a new official release is rolled out
from the branch.

With this scheme introduced, version specific library subdirectory
names only need to have {MAJOR}.{MINOR} in it, and user can safely
upgrade ruby to a new teeny version without having to rebuild and
reinstall already installed libraries.

[Figure: Branch Tree]

--o-----------------------o----------(trunk)
   \                       \
    o--o--o--o--(ruby_2_1)  o--o--...--(ruby_2_2)
        \  \  \                 \
         \  \  \                 o--[v2_2_0_0]--...--(ruby_2_2_0)
          \  \  \
           \  \  o--[v2_1_2_0]--[v2_1_2_ppp]--...--(ruby_2_1_2)
            \  \
             \  o--[v2_1_1_0]--[v2_1_1_ppp]--...--(ruby_2_1_1)
              \
               o--[v2_1_0_0]--[v2_1_0_ppp]--...--(ruby_2_1_0)

=end

[knu (Akinori MUSHA)]

• Description updated (diff)

[nobu (Nobuyoshi Nakada)]

• Assignee changed from nobu (Nobuyoshi Nakada) to knu (Akinori MUSHA)

• File noname noname added

At Fri, 30 Aug 2013 21:49:34 +0900,
I wrote:

misc #8835: Introducing a semantic versioning scheme and branching policy
https://bugs.ruby-lang.org/issues/8835

　DevelopersMeeting20130831Japanでのプレゼンのために、[ruby-core:56878]
[misc #8835] を日本語で補足します。

　直接的なきっかけは [ruby-list:49555] のスレッドです。元の問題自体は、
RubyGemsを直すべきだと思います。ただ、1.8, 1.9, 2.0と、バージョンの運用
状況が毎回なんとなしに変わってきており、PATCHLEVELまであるRUBY_VERSION
がAPI互換性については多くを示さず、RUBY_API_VERSIONが別途あるというのは
ちょっといただけない状況だと思いました。

　そこで、この提案は [MAJOR & MINOR, TEENY, PATCHLEVEL] がSemantic
Versioning (http://semver.org/)に沿うように再定義しようというものです。
Ruby自体をAPI互換性を考慮したバージョン体系にすることによって、1.9で導
入されたもののあまり有意義に運用されなかったRUBY_API_VERSIONと統一し、
両者の不一致から来る潜在的なユーザの混乱および互換性に関する懸念の解消
を図ります。

　開発陣におけるABI互換性についての意識は高まっており、試験的ながら
Ruby-CIにもABIチェックが入っているので、Semantic Versioningを運用してい
くことが現実的に可能だと思います。

　TEENYが9までしか使えないという縛りはありますが、MAJOR.MINOR.0のリリー
ス後に、APIを追加・拡張したリリースを9回も行う必要は薄く、いつでも追加・
拡張をやめてバグ修正のみのフェーズに移行できるので、枯渇を気にする必要
はないでしょう。

　機能追加を行った次のTEENYリリースを準備中に、もしセキュリティ等に関す
るクリティカルな修正が必要になった場合は、それ以外の修正も入った次の
TEENYリリース準備ブランチの安定を確認する必要はなく、現行のTEENYリリー
スブランチからすぐにPATCHLEVELリリースを行えます。つまり、PATCHLEVELは
主にセキュリティ修正レベルという意味づけになり、リリースする側の手間が
減ることはもちろん、安定性や互換性を重視するベンダーやユーザのニーズに
応えるものです。

　なお、1.8系列および1.9系列ではTEENYの違いでもABI/API非互換があったの
で各TEENYごとにそれぞれ保守を続ける必要が生じていましたが、このスキーム
では、新しいTEENYが出たら上位互換性を盾に1つ前のTEENYの保守をすぐに打ち
切れます。ただ、継続を望むベンダーがいれば、古いTEENYのブランチを保守し
てもらうのもありでしょう。（coreチームとしてのリリースは行わないでしょ
うが）

　ブランチの作成・運用手順についても記述しています。これはFreeBSDや
NetBSDに倣ったもので、特に独自な点はありません。

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

[kosaki (Motohiro KOSAKI)]

2013/8/30 Akinori MUSHA [e-mail]:

At Fri, 30 Aug 2013 21:49:34 +0900,
I wrote:

misc #8835: Introducing a semantic versioning scheme and branching policy
https://bugs.ruby-lang.org/issues/8835

　DevelopersMeeting20130831Japanでのプレゼンのために、[ruby-core:56878]
[misc #8835] を日本語で補足します。

　直接的なきっかけは [ruby-list:49555] のスレッドです。元の問題自体は、
RubyGemsを直すべきだと思います。ただ、1.8, 1.9, 2.0と、バージョンの運用
状況が毎回なんとなしに変わってきており、PATCHLEVELまであるRUBY_VERSION
がAPI互換性については多くを示さず、RUBY_API_VERSIONが別途あるというのは
ちょっといただけない状況だと思いました。

　そこで、この提案は [MAJOR & MINOR, TEENY, PATCHLEVEL] がSemantic
Versioning (http://semver.org/)に沿うように再定義しようというものです。
Ruby自体をAPI互換性を考慮したバージョン体系にすることによって、1.9で導
入されたもののあまり有意義に運用されなかったRUBY_API_VERSIONと統一し、
両者の不一致から来る潜在的なユーザの混乱および互換性に関する懸念の解消
を図ります。

　開発陣におけるABI互換性についての意識は高まっており、試験的ながら
Ruby-CIにもABIチェックが入っているので、Semantic Versioningを運用してい
くことが現実的に可能だと思います。

　TEENYが9までしか使えないという縛りはありますが、MAJOR.MINOR.0のリリー
ス後に、APIを追加・拡張したリリースを9回も行う必要は薄く、いつでも追加・
拡張をやめてバグ修正のみのフェーズに移行できるので、枯渇を気にする必要
はないでしょう。

えっ。
いまのパッチレベルリリースはほとんどのケースでシンボルの追加があると思いますが。

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

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

実際問題として1.9.3とかp0と最新では結構な非互換が検出されてます。

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

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

　機能追加を行った次のTEENYリリースを準備中に、もしセキュリティ等に関す
るクリティカルな修正が必要になった場合は、それ以外の修正も入った次の
TEENYリリース準備ブランチの安定を確認する必要はなく、現行のTEENYリリー
スブランチからすぐにPATCHLEVELリリースを行えます。つまり、PATCHLEVELは
主にセキュリティ修正レベルという意味づけになり、リリースする側の手間が
減ることはもちろん、安定性や互換性を重視するベンダーやユーザのニーズに
応えるものです。

モチベーションは理解できます。少なくともパッチレベルでの非互換はなくしたいですね。

実際の運用として、p0の後の最初の２つぐらいのパッチレベルリリースは非互換ありでも許されてきた経緯があり（どうせp0なんか使うやついないという判断により）、どのタイミングで非互換なしになるのかはメンテナーに任されていた部分が大だったと思います。
これが、当初の２−３回のリリースはTEENYあげる。（Rubyコミュニティが99.9%のユーザが被害を受けないと考えるような）小さな非互換もありうる。それ以降はパッチレベルでsymbol
削除方向の非互換はなし。とかだったら分かりやすいし、ツール支援もしやすいので賛成しやすいですね。

ではでは。

[nobu (Nobuyoshi Nakada)]

(13/08/31 8:49), KOSAKI Motohiro wrote:

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

固定だったら無意味なので、パッチレベルを廃止してTEENYを上げてけばいいんじゃないですかね。
バージョンを比較したければGem::Version使えってことで。

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

[kosaki (Motohiro KOSAKI)]

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

固定だったら無意味なので、パッチレベルを廃止してTEENYを上げてけばいいんじゃないですかね。
バージョンを比較したければGem::Version使えってことで。

既存のコードを動かなくさせるメリットが見つけられませんでした。美しさにこだわるところじゃないと思う

• File noname noname added

At Fri, 30 Aug 2013 19:49:59 -0400,
KOSAKI Motohiro wrote:

えっ。
いまのパッチレベルリリースはほとんどのケースでシンボルの追加があると思いますが。

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

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

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

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

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

実際問題として1.9.3とかp0と最新では結構な非互換が検出されてます。

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

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

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

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

　機能追加を行った次のTEENYリリースを準備中に、もしセキュリティ等に関す
るクリティカルな修正が必要になった場合は、それ以外の修正も入った次の
TEENYリリース準備ブランチの安定を確認する必要はなく、現行のTEENYリリー
スブランチからすぐにPATCHLEVELリリースを行えます。つまり、PATCHLEVELは
主にセキュリティ修正レベルという意味づけになり、リリースする側の手間が
減ることはもちろん、安定性や互換性を重視するベンダーやユーザのニーズに
応えるものです。

モチベーションは理解できます。少なくともパッチレベルでの非互換はなくしたいですね。

実際の運用として、p0の後の最初の２つぐらいのパッチレベルリリースは非互換ありでも許されてきた経緯があり（どうせp0なんか使うやついないという判断により）、どのタイミングで非互換なしになるのかはメンテナーに任されていた部分が大だったと思います。

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

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

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

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

[kosaki (Motohiro KOSAKI)]

えっ。
いまのパッチレベルリリースはほとんどのケースでシンボルの追加があると思いますが。

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

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

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

ちょっと自身がなかったので1.8.7のリリース回数を調べてみたのですがp0と合わせて22回
リリースが行われています。
いくつかはパッチレベルに出来るのでしょうが、9回あれば楽勝というレベルかというと
ちょっと自身が持てませんでした。

前回のメールで書いたとおり、rubyレベルの変更が１つでも入ったらTEENYをbumpしないと
いけない提案に見えるためです。

[ ] ruby-1.8.7-p17.tar.bz2 10-Jun-2008 03:40 3.9M
[ ] ruby-1.8.7-p22.tar.bz2 21-Jun-2008 03:30 3.9M
[ ] ruby-1.8.7-p71.tar.bz2 08-Aug-2008 20:09 3.9M
[ ] ruby-1.8.7-p72.tar.bz2 11-Aug-2008 18:40 3.9M
[ ] ruby-1.8.7-p160.tar.bz2 09-Apr-2009 22:44 3.9M
[ ] ruby-1.8.7-p173.tar.bz2 10-Jun-2009 17:50 4.0M
[ ] ruby-1.8.7-p174.tar.bz2 16-Jun-2009 17:58 4.0M
[ ] ruby-1.8.7-p248.tar.bz2 25-Dec-2009 03:37 4.0M
[ ] ruby-1.8.7-p249.tar.bz2 11-Jan-2010 04:32 4.0M
[ ] ruby-1.8.7-p299.tar.bz2 24-Jun-2010 09:36 4.0M
[ ] ruby-1.8.7-p301.tar.bz2 16-Aug-2010 21:43 4.0M
[ ] ruby-1.8.7-p302.tar.bz2 17-Aug-2010 01:32 4.0M
[ ] ruby-1.8.7-p330.tar.bz2 24-Dec-2010 21:33 4.0M
[ ] ruby-1.8.7-p334.tar.bz2 19-Feb-2011 06:43 4.0M
[ ] ruby-1.8.7-p352.tar.bz2 03-Jul-2011 03:54 4.0M
[ ] ruby-1.8.7-p357.tar.bz2 29-Dec-2011 06:50 4.0M
[ ] ruby-1.8.7-p358.tar.bz2 17-Feb-2012 03:01 4.0M
[ ] ruby-1.8.7-p370.tar.bz2 30-Jun-2012 07:18 4.0M
[ ] ruby-1.8.7-p371.tar.bz2 12-Oct-2012 22:32 4.1M
[ ] ruby-1.8.7-p373.tar.bz2 28-Jun-2013 05:24 4.1M
[ ] ruby-1.8.7-p374.tar.bz2 28-Jun-2013 05:57 4.1M
[ ] ruby-1.8.7.tar.bz2 01-Jun-2008 09:19 3.9M

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

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

そうですね。同意します

実際問題として1.9.3とかp0と最新では結構な非互換が検出されてます。

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

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

全然知らないのですが、gemはパッチレベルはチェックできないもの？

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

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

　 機能追加を行った次のTEENYリリースを準備中に、もしセキュリティ等に関す
るクリティカルな修正が必要になった場合は、それ以外の修正も入った次の
TEENYリリース準備ブランチの安定を確認する必要はなく、現行のTEENYリリー
スブランチからすぐにPATCHLEVELリリースを行えます。つまり、PATCHLEVELは
主にセキュリティ修正レベルという意味づけになり、リリースする側の手間が
減ることはもちろん、安定性や互換性を重視するベンダーやユーザのニーズに
応えるものです。

モチベーションは理解できます。少なくともパッチレベルでの非互換はなくしたいですね。

実際の運用として、p0の後の最初の２つぐらいのパッチレベルリリースは非互換ありでも許されてきた経緯があり（どうせp0なんか使うやついないという判断により）、どのタイミングで非互換なしになるのかはメンテナーに任されていた部分が大だったと思います。

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

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

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

はい。細かいところで気になるところはありますが、総論としては賛成です。

[naruse (Yui NARUSE)]

ABI 互換性をどう考え、どう守り、どう示すのかは Ruby 1.9.1 以降幾度となく議論されていた懸案で、
その中で共有されてきたいくつかの前提が、本提案では無視されているように思います。

具体的には、

• 我々はABI後方互換性を保っている気でいる（が、しばしば壊れてしまうことがある） → 事前の人力のアノテーションでは回避出来ないと言うこと
• 脆弱性が発見されたら生きている全てのブランチでリリースが必要
• メンテナンスコストは生きているブランチ数に応じて増える
• 2年程度は使い続けられるブランチが欲しい
• 1.9.1-1.9.3 ではABI互換性は保たれたという公式見解 (なぜなら最近まで互換性破壊を指摘する人がいなかったから)
• 2.0.0 では 1.9.x からの ABI 互換性を破壊したという見解
  あたりですか。

過去の議論は例えば以下のスレッドがあります。

• [ruby-core:19113]
• [ruby-dev:43152]
• [ruby-dev:36655]
• [ruby-dev:36889]
• [ruby-dev:44604]

で、提案は現状をまとめ、あるべき姿を動機と共に示し、差分を提案すべき所、
現状の認識がちょっと違う気がするし、あるべき姿はあるけれど動機が抜けているのでなんかわかりづらいです。
そもそも、このスレって「互換性を守ろう」って話と「互換性を壊そう」って話が混ざってますよね。
開発者会議で akr さんが「shim がやりたいんだよね?」と指摘してらっしゃいましたが、
その辺は互換性を守る話ときちんと分離してください。

kosaki さんの Microsoft のプロダクトライフサイクルっぽい提案はー、どうなんでしょうね。
ツールは別に基準となる patch level を与えればいいだけの話で、
もっぱらマーケティング的な観点で考えるべきもののように感じます。

P.S.
英語のチケットに日本語がぶら下がっていると英語しか読めない人から見て感じが悪いので、
そうしたいときには別に日本語のチケットを作ってそこからぶら下げるようにして下さい。

[steveklabnik (Steve Klabnik)]

英語のチケットに日本語がぶら下がっていると英語しか読めない人から見て感じが悪いので、
そうしたいときには別に日本語のチケットを作ってそこからぶら下げるようにして下さい。

I only know a very small amount of Japanese, but the Google Translate of your post was very understandable.

[zzak (zzak _)]

We have accepted hsbt's proposal: https://gist.github.com/sorah/7803201

[zzak (zzak _)]

I have submitted announcement for semantic versioning scheme to ruby-lang.org: https://github.com/ruby/www.ruby-lang.org/pull/468

[vo.x (Vit Ondruch)]

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

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.

Thanks for clarification.

[luislavena (Luis Lavena)]

vo.x (Vit Ondruch) wrote:

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

Hello Vit,

Is my understanding that semantic versioning will apply starting from 2.1.0 and not backward applied to 2.0.0

2.0.0 will continue the same version schema it has but Ruby 2.1 will bump TEENY version number on every release.

Patchlevel will still be increased, but that will refer to the number of "patches" it receive between releases.

[hsbt (Hiroshi SHIBATA)]

• Target version changed from 2.1.0 to 2.2.0

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Closed

We already applied to use SemVer 'like' versioning after Ruby 2.1.

see also. https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/