Forum: Ruby-core [ruby-trunk - misc #8835][Open] Introducing a semantic versioning scheme and branching policy

6789224081b49822eb70f6740beb5ed5?d=identicon&s=25 knu (Akinori MUSHA) (Guest)
on 2013-08-30 14:50
(Received via mailing list)
Issue #8835 has been reported by knu (Akinori MUSHA).

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

Author: knu (Akinori MUSHA)
Status: Open
Priority: Normal
Assignee: nobu (Nobuyoshi Nakada)
Category: misc
Target version: current: 2.1.0


=begin
[This is a presentation for
((<DevelopersMeeting20130831Japan|URL:https://bugs.ruby-lang.org/projects/ruby/wiki/Deve...)).]


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.  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
6789224081b49822eb70f6740beb5ed5?d=identicon&s=25 knu (Akinori MUSHA) (Guest)
on 2013-08-30 15:07
(Received via mailing list)
Issue #8835 has been updated by knu (Akinori MUSHA).

Description updated


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

Author: knu (Akinori MUSHA)
Status: Open
Priority: Normal
Assignee: nobu (Nobuyoshi Nakada)
Category: misc
Target version: current: 2.1.0


=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
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2013-08-30 16:26
(Received via mailing list)
Issue #8835 has been updated by nobu (Nobuyoshi Nakada).

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


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

Author: knu (Akinori MUSHA)
Status: Open
Priority: Normal
Assignee: knu (Akinori MUSHA)
Category: misc
Target version: current: 2.1.0


=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
74f896b312b786ee75a18073941e2457?d=identicon&s=25 Akinori MUSHA (Guest)
on 2013-08-30 19:30
(Received via mailing list)
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

$B!!(BDevelopersMeeting20130831Japan$B$G$N%W%l%<%s$N$?$a$K!"(B[ruby-core:56878]
[misc #8835] $B$rF|K\8l$GJdB-$7$^$9!#(B

$B!!D>@\E*$J$-$C$+$1$O(B [ruby-list:49555]
$B$N%9%l%C%I$G$9!#85$NLdBj<+BN$O!"(B
RubyGems$B$rD>$9$Y$-$@$H;W$$$^$9!#$?$@!"(B1.8, 1.9,
2.0$B$H!"%P!<%8%g%s$N1?MQ(B
$B>u67$,Kh2s$J$s$H$J$7$KJQ$o$C$F$-$F$*$j!"(BPATCHLEVEL$B$^$G$"$k(BRUBY_VERSION
$B$,(BAPI$B8_49@-$K$D$$$F$OB?$/$r<($5$:!"(BRUBY_API_VERSION$B$,JLES$"$k$H$$$&$N$O(B
$B$A$g$C$H$$$?$@$1$J$$>u67$@$H;W$$$^$7$?!#(B

$B!!$=$3$G!"$3$NDs0F$O(B [MAJOR & MINOR, TEENY, PATCHLEVEL]
$B$,(BSemantic
Versioning
(http://semver.org/)$B$K1h$&$h$&$K:FDj5A$7$h$&$H$$$...
Ruby$B<+BN$r(BAPI$B8_49@-$r9MN8$7$?%P!<%8%g%sBN7O$K$9$k$3$H$K$h$C$F!"(B1.9$B$GF3(B
$BF~$5$l$?$b$N$N$"$^$jM-0U5A$K1?MQ$5$l$J$+$C$?(BRUBY_API_VERSION$B$HE}0l$7!"(B
$BN><T$NIT0lCW$+$iMh$k@x:_E*$J%f!<%6$N:.Mp$*$h$S8_49@-$K4X$9$k7|G0$N2r>C(B
$B$r?^$j$^$9!#(B

$B!!3+H/?X$K$*$1$k(BABI$B8_49@-$K$D$$$F$N0U<1$O9b$^$C$F$*$j!";n83E*$J$,$i(B
Ruby-CI$B$K$b(BABI$B%A%'%C%/$,F~$C$F$$$k$N$G!"(BSemantic
Versioning$B$r1?MQ$7$F$$(B
$B$/$3$H$,8=<BE*$K2DG=$@$H;W$$$^$9!#(B

$B!!(BTEENY$B$,(B9$B$^$G$7$+;H$($J$$$H$$$&G{$j$O$"$j$^$9$,!"(BMAJOR.MINOR.0$B$N%j%j!<(B
$B%98e$K!"(BAPI$B$rDI2C!&3HD%$7$?%j%j!<%9$r(B9$B2s$b9T$&I,MW$OGv$/!"$$$D$G$bDI2C!&(B
$B3HD%$r$d$a$F%P%0=$@5$N$_$N%U%'!<%:$K0\9T$G$-$k$N$G!"8O3i$r5$$K$9$kI,MW(B
$B$O$J$$$G$7$g$&!#(B

$B!!5!G=DI2C$r9T$C$?<!$N(BTEENY$B%j%j!<%9$r=`HwCf$K!"$b$7%;%-%e%j%F%#Ey$K4X$9(B
$B$k%/%j%F%#%+%k$J=$@5$,I,MW$K$J$C$?>l9g$O!"$=$l0J30$N=$@5$bF~$C$?<!$N(B
TEENY$B%j%j!<%9=`Hw%V%i%s%A$N0BDj$r3NG'$9$kI,MW$O$J$/!"8=9T$N(BTEENY$B%j%j!<(B
$B%9%V%i%s%A$+$i$9$0$K(BPATCHLEVEL$B%j%j!<%9$r9T$($^$9!#$D$^$j!"(BPATCHLEVEL$B$O(B
$B<g$K%;%-%e%j%F%#=$@5%l%Y%k$H$$$&0UL#$E$1$K$J$j!"%j%j!<%9$9$kB&$N<j4V$,(B
$B8:$k$3$H$O$b$A$m$s!"0BDj@-$d8_49@-$r=E;k$9$k%Y%s%@!<$d%f!<%6$N%K!<%:$K(B
$B1~$($k$b$N$G$9!#(B

$B!!$J$*!"(B1.8$B7ONs$*$h$S(B1.9$B7ONs$G$O(BTEENY$B$N0c$$$G$b(BABI/API$BHs8_49$,$"$C$?$N(B
$B$G3F(BTEENY$B$4$H$K$=$l$>$lJ]<i$rB3$1$kI,MW$,@8$8$F$$$^$7$?$,!"$3$N%9%-!<%`(B
$B$G$O!"?7$7$$(BTEENY$B$,=P$?$i>e0L8_49@-$r=b$K(B1$B$DA0$N(BTEENY$B$NJ]<i$r$9$0$KBG$A(B
$B@Z$l$^$9!#$?$@!"7QB3$rK>$`%Y%s%@!<$,$$$l$P!"8E$$(BTEENY$B$N%V%i%s%A$rJ]<i$7(B
$B$F$b$i$&$N$b$"$j$G$7$g$&!#!J(Bcore$B%A!<%`$H$7$F$N%j%j!<%9$O9T$o$J$$$G$7$g(B
$B$&$,!K(B

$B!!%V%i%s%A$N:n@.!&1?MQ<j=g$K$D$$$F$b5-=R$7$F$$$^$9!#$3$l$O(BFreeBSD$B$d(B
NetBSD$B$KJo$C$?$b$N$G!"FC$KFH<+$JE@$O$"$j$^$;$s!#(B
02da662c083396641da96c1d32fc86ed?d=identicon&s=25 KOSAKI Motohiro (Guest)
on 2013-08-31 01:51
(Received via mailing list)
2013/8/30 Akinori MUSHA <knu@idaemons.org>:
> $B>u67$,Kh2s$J$s$H$J$7$KJQ$o$C$F$-$F$*$j!"(BPATCHLEVEL$B$^$G$"$k(BRUBY_VERSION
> $B!!3+H/?X$K$*$1$k(BABI$B8_49@-$K$D$$$F$N0U<1$O9b$^$C$F$*$j!";n83E*$J$,$i(B
> Ruby-CI$B$K$b(BABI$B%A%'%C%/$,F~$C$F$$$k$N$G!"(BSemantic
Versioning$B$r1?MQ$7$F$$(B
> $B$/$3$H$,8=<BE*$K2DG=$@$H;W$$$^$9!#(B
>
>
$B!!(BTEENY$B$,(B9$B$^$G$7$+;H$($J$$$H$$$&G{$j$O$"$j$^$9$,!"(BMAJOR.MINOR.0$B$N%j%j!<(B
>
$B%98e$K!"(BAPI$B$rDI2C!&3HD%$7$?%j%j!<%9$r(B9$B2s$b9T$&I,MW$OGv$/!"$$$D$G$bDI2C!&(B
> $B3HD%$r$d$a$F%P%0=$@5$N$_$N%U%'!<%:$K0\9T$G$-$k$N$G!"8O3i$r5$$K$9$kI,MW(B
> $B$O$J$$$G$7$g$&!#(B

$B$($C!#(B
$B$$$^$N%Q%C%A%l%Y%k%j%j!<%9$O$[$H$s$I$N%1!<%9$G%7%s%\%k$NDI2C$,$"$k$H;W$$$^$9$,!#(B

$B$"$H!"(BRuby$B$N%/%i%9$O!V3+$$$F$$$k!W$N$G!"$I$s$J%P%0%U%#%C%/%9$G$"$C$F$b$"$d$7$2$J%b%s%-!<%Q%C%A%c!<$5$s$O$.$c$C$H$$$&%j%9%/$O$"$k$o$1$G!"$3$N%k!<%k$@$H%Q%C%A%l%Y%k$@$1$G$9$`%1!<%9$,$[$\L5$/$J$k$s$8$c$J$$$+$J$"!#(B

$B3+H/?X$K$*$1$k(BABI$B8_49@-$K$D$$$F$N0U<1$O9b$^$C$F$$$k$H$$$&G'<1$K$b2{5?E*$G!"0U<1$7$F$$$k?M$O$7$F$$$k$7$7$F$$$J$$?M$OA4A3$7$F$$$J$$$N$G!"%a%s%F%J!<$NIi2Y$r8:$i$9$K$O%3%_%C%?!<$NA10U$@$1$G$O$@$a$G%D!<%k$N=u$1$,$$$k$H$$$&$N$,(B
ABI checker$BF3F~;~$N%P%C%/%0%i%&%s%I%b%A%Y!<%7%g%s$H$7$F$"$j$^$7$?!#(B

$B<B:]LdBj$H$7$F(B1.9.3$B$H$+(Bp0$B$H:G?7$G$O7k9=$JHs8_49$,8!=P$5$l$F$^$9!#(B

$B$H$$$&$o$1$G!"%+%&%s%?!<%W%m%]!<%5%k$H$7$F!"(BTEENY$B$r(B0$B8GDj$K$7$F!"%Q%C%A%l%Y%k$O(Bsymbol$B:o8:J}8~$NHs8_49$O$7$J$$$,!"(Bsymbol$BDI2C$NHs8_49$O$"$j!J(Brb_,
ruby_
prefix$B$N4X?t$r<+%b%8%e!<%k$K$D$+$&3HD%$,0-$$!K$H$$$&(BRuby$B%*%l%*%l%k!<%k$r7QB3$9$k$3$H$rDs0F$7$^$9!#(B

$B$D$$$G$K!"$$$^$O(BRuby$B%l%Y%k$NHs8_49$K$D$$$F!"0l@Z%D!<%k;Y1g$,$J$$>u67$G$9$N$G!"$3$A$i$K$D$$$F$bBP:v$K4X$9$k0U8+$r9-$/Jg=8$7$?$$$H$3$m$G$9!#(B

>
> $B!!5!G=DI2C$r9T$C$?<!$N(BTEENY$B%j%j!<%9$r=`HwCf$K!"$b$7%;%-%e%j%F%#Ey$K4X$9(B
> $B$k%/%j%F%#%+%k$J=$@5$,I,MW$K$J$C$?>l9g$O!"$=$l0J30$N=$@5$bF~$C$?<!$N(B
> TEENY$B%j%j!<%9=`Hw%V%i%s%A$N0BDj$r3NG'$9$kI,MW$O$J$/!"8=9T$N(BTEENY$B%j%j!<(B
>
$B%9%V%i%s%A$+$i$9$0$K(BPATCHLEVEL$B%j%j!<%9$r9T$($^$9!#$D$^$j!"(BPATCHLEVEL$B$O(B
> $B<g$K%;%-%e%j%F%#=$@5%l%Y%k$H$$$&0UL#$E$1$K$J$j!"%j%j!<%9$9$kB&$N<j4V$,(B
> $B8:$k$3$H$O$b$A$m$s!"0BDj@-$d8_49@-$r=E;k$9$k%Y%s%@!<$d%f!<%6$N%K!<%:$K(B
> $B1~$($k$b$N$G$9!#(B

$B%b%A%Y!<%7%g%s$OM}2r$G$-$^$9!#>/$J$/$H$b%Q%C%A%l%Y%k$G$NHs8_49$O$J$/$7$?$$$G$9$M!#(B

$B<B:]$N1?MQ$H$7$F!"(Bp0$B$N8e$N:G=i$N#2$D$0$i$$$N%Q%C%A%l%Y%k%j%j!<%9$OHs8_49$"$j$G$b5v$5$l$F$-$?7P0^$,$"$j!J$I$&$;(Bp0$B$J$s$+;H$&$d$D$$$J$$$H$$$&H=CG$K$h$j!K!"$I$N%?%$%_%s%0$GHs8_49$J$7$K$J$k$N$+$O%a%s%F%J!<$KG$$5$l$F$$$?ItJ,$,Bg$@$C$?$H;W$$$^$9!#(B
$B$3$l$,!"Ev=i$N#2!]#32s$N%j%j!<%9$O(BTEENY$B$"$2$k!#!J(BRuby$B%3%_%e%K%F%#$,(B99.9%$B$N%f!<%6$,Ho32$r<u$1$J$$$H9M$($k$h$&$J!K>.$5$JHs8_49$b$"$j$&$k!#$=$l0J9_$O%Q%C%A%l%Y%k$G(Bsymbol
$B:o=|J}8~$NHs8_49$O$J$7!#$H$+$@$C$?$iJ,$+$j$d$9$$$7!"%D!<%k;Y1g$b$7$d$9$$$N$G;?@.$7$d$9$$$G$9$M!#(B

$B$G$O$G$O!#(B
F1d6cc2b735bfd82c8773172da2aeab9?d=identicon&s=25 Nobuyoshi Nakada (nobu)
on 2013-08-31 02:45
(Received via mailing list)
(13/08/31 8:49), KOSAKI Motohiro wrote:
>
$B$H$$$&$o$1$G!"%+%&%s%?!<%W%m%]!<%5%k$H$7$F!"(BTEENY$B$r(B0$B8GDj$K$7$F!"%Q%C%A%l%Y%k$O(Bsymbol$B:o8:J}8~$NHs8_49$O$7$J$$$,!"(Bsymbol$BDI2C$NHs8_49$O$"$j!J(Brb_,
> ruby_
prefix$B$N4X?t$r<+%b%8%e!<%k$K$D$+$&3HD%$,0-$$!K$H$$$&(BRuby$B%*%l%*%l%k!<%k$r7QB3$9$k$3$H$rDs0F$7$^$9!#(B

$B8GDj$@$C$?$iL50UL#$J$N$G!"%Q%C%A%l%Y%k$rGQ;_$7$F(BTEENY$B$r>e$2$F$1$P$$$$$s$8$c$J$$$G$9$+$M!#(B
$B%P!<%8%g%s$rHf3S$7$?$1$l$P(BGem::Version$B;H$($C$F$3$H$G!#(B
02da662c083396641da96c1d32fc86ed?d=identicon&s=25 KOSAKI Motohiro (Guest)
on 2013-08-31 04:09
(Received via mailing list)
>>
$B$H$$$&$o$1$G!"%+%&%s%?!<%W%m%]!<%5%k$H$7$F!"(BTEENY$B$r(B0$B8GDj$K$7$F!"%Q%C%A%l%Y%k$O(Bsymbol$B:o8:J}8~$NHs8_49$O$7$J$$$,!"(Bsymbol$BDI2C$NHs8_49$O$"$j!J(Brb_,
>> ruby_
prefix$B$N4X?t$r<+%b%8%e!<%k$K$D$+$&3HD%$,0-$$!K$H$$$&(BRuby$B%*%l%*%l%k!<%k$r7QB3$9$k$3$H$rDs0F$7$^$9!#(B
>
>
$B8GDj$@$C$?$iL50UL#$J$N$G!"%Q%C%A%l%Y%k$rGQ;_$7$F(BTEENY$B$r>e$2$F$1$P$$$$$s$8$c$J$$$G$9$+$M!#(B
> $B%P!<%8%g%s$rHf3S$7$?$1$l$P(BGem::Version$B;H$($C$F$3$H$G!#(B

$B4{B8$N%3!<%I$rF0$+$J$/$5$;$k%a%j%C%H$,8+$D$1$i$l$^$;$s$G$7$?!#H~$7$5$K$3$@$o$k$H$3$m$8$c$J$$$H;W$&(B
74f896b312b786ee75a18073941e2457?d=identicon&s=25 Akinori MUSHA (Guest)
on 2013-08-31 05:02
(Received via mailing list)
At Fri, 30 Aug 2013 19:49:59 -0400,
KOSAKI Motohiro wrote:
> $B$($C!#(B
>
$B$$$^$N%Q%C%A%l%Y%k%j%j!<%9$O$[$H$s$I$N%1!<%9$G%7%s%\%k$NDI2C$,$"$k$H;W$$$^$9$,!#(B

$B$O$$!#0UL#$rJQ$($k$H$$$&Ds0F$J$N$G!#2>$K(B 2.0
$B7ONs$K?7$7$$%9%-!<%`$rE,MQ(B
$B$7$F$$$?$H$9$k$H!"%Q%C%A%l%Y%k%j%j!<%9$OH>G/$A$g$C$H7P$A$^$7$?$,$^$@(B2$B2s(B
$B$@$1$J$N$G8=:_(B 2.0.2
$B$K$J$C$F$*$j!"2>$KG/Fb$K$"$H(B2$B2s$/$i$$5!G=DI2C$r4^(B
$B$`%j%j!<%9$r=P$7$?$H$7$F(B 2.0.4$B!"$=$3$G(B 2.1.0
$B$,=P$F!"A0J}8_49@-$r2~A1$9(B
$B$k5!G=DI2C$d3HD%$r9T$$$^$7$g$&$H$$$&$H$-$K$"$H(B5$B2sJQ?H$r;D$7$F$$$k46$8$G(B
$B$9!#==J,$G$O$J$$$G$7$g$&$+!#!J8eJ}Hs8_49@-$K$D$$$F$O8e=R!K(B

>
$B$"$H!"(BRuby$B$N%/%i%9$O!V3+$$$F$$$k!W$N$G!"$I$s$J%P%0%U%#%C%/%9$G$"$C$F$b$"$d$7$2$J%b%s%-!<%Q%C%A%c!<$5$s$O$.$c$C$H$$$&%j%9%/$O$"$k$o$1$G!"$3$N%k!<%k$@$H%Q%C%A%l%Y%k$@$1$G$9$`%1!<%9$,$[$\L5$/$J$k$s$8$c$J$$$+$J$"!#(B

$B%Q%C%A%l%Y%k$@$1$G:Q$^$J$$JQ99$r2C$($?>e$G$N%j%j!<%9$NM>CO$,(B9$B2s$"$l$P!"(B
$B8=:_$N%j%j!<%9%5%$%/%k$r8+$k$K==J,$G$O$J$$$+$H$$$&$N$,<g;]$G$9!#(B

>
$B3+H/?X$K$*$1$k(BABI$B8_49@-$K$D$$$F$N0U<1$O9b$^$C$F$$$k$H$$$&G'<1$K$b2{5?E*$G!"0U<1$7$F$$$k?M$O$7$F$$$k$7$7$F$$$J$$?M$OA4A3$7$F$$$J$$$N$G!"%a%s%F%J!<$NIi2Y$r8:$i$9$K$O%3%_%C%?!<$NA10U$@$1$G$O$@$a$G%D!<%k$N=u$1$,$$$k$H$$$&$N$,(B
> ABI checker$BF3F~;~$N%P%C%/%0%i%&%s%I%b%A%Y!<%7%g%s$H$7$F$"$j$^$7$?!#(B

$B$=$b$=$b8=:_(BAPI
version$B$H$$$&$N$,<B$O2?$NLr3d$b2L$?$7$F$$$J$$!J(B1.9$B$G$b(B
2.0$B$G$b(BTEENY$B$9$i>e$,$C$F$$$J$$$78eJ}8_49@-$bJ]$?$l$F$$$J$$!K>u67$G$9$,!"(B
$B>/$J$/$H$bDI2C$d3HD%$,$"$k$N$G>e$2$k$Y$-!":o=|$dJQ99$,$"$k$N$G%P%C%/%]!<(B
$B%HIT2D!"$H$$$&H=CG$,%D!<%k$N;Y1g$G$"$kDxEY%G%8%?%k$K$G$-$k$h$&$K$J$j$^(B
$B$7$?!#(B

> $B<B:]LdBj$H$7$F(B1.9.3$B$H$+(Bp0$B$H:G?7$G$O7k9=$JHs8_49$,8!=P$5$l$F$^$9!#(B
>
>
$B$H$$$&$o$1$G!"%+%&%s%?!<%W%m%]!<%5%k$H$7$F!"(BTEENY$B$r(B0$B8GDj$K$7$F!"%Q%C%A%l%Y%k$O(Bsymbol$B:o8:J}8~$NHs8_49$O$7$J$$$,!"(Bsymbol$BDI2C$NHs8_49$O$"$j!J(Brb_,
> ruby_
prefix$B$N4X?t$r<+%b%8%e!<%k$K$D$+$&3HD%$,0-$$!K$H$$$&(BRuby$B%*%l%*%l%k!<%k$r7QB3$9$k$3$H$rDs0F$7$^$9!#(B

$B$=$l$@$H!"DI2C$5$l$?%7%s%\%k$K0MB8$7$?%P%$%J%jJ*$rG[I[$9$k$H$-$K%P!<%8%g(B
$B%sHV9f$G%A%'%C%/$G$-$J$$$N$,:$$j$^$9!#%S%k%I;~$d<B9T;~$O(Bextconf.rb
$B$d(B
respond_to?
$BEy!9$G%A%'%C%/$b$G$-$^$9$,!"(BRubyGems$B$r4^$`%Q%C%1!<%8%7%9%F(B
$B%`$,%$%s%9%H!<%k$N:]$K%P!<%8%g%sHV9f$GHf3S$9$k$7$+$J$$$H$$$&$H$3$m$K%K!<(B
$B%:$,$"$j$^$9!#(B

>
$B$D$$$G$K!"$$$^$O(BRuby$B%l%Y%k$NHs8_49$K$D$$$F!"0l@Z%D!<%k;Y1g$,$J$$>u67$G$9$N$G!"$3$A$i$K$D$$$F$bBP:v$K4X$9$k0U8+$r9-$/Jg=8$7$?$$$H$3$m$G$9!#(B

$B$=$&$G$9$M!#$=$3$O2]Bj$H$7$FG'<1$7$^$9!#(B

>
$B<B:]$N1?MQ$H$7$F!"(Bp0$B$N8e$N:G=i$N#2$D$0$i$$$N%Q%C%A%l%Y%k%j%j!<%9$OHs8_49$"$j$G$b5v$5$l$F$-$?7P0^$,$"$j!J$I$&$;(Bp0$B$J$s$+;H$&$d$D$$$J$$$H$$$&H=CG$K$h$j!K!"$I$N%?%$%_%s%0$GHs8_49$J$7$K$J$k$N$+$O%a%s%F%J!<$KG$$5$l$F$$$?ItJ,$,Bg$@$C$?$H;W$$$^$9!#(B
1.9.0 $B$O%W%l%S%e!<HG!"(B 1.9.1
$B$O%G%Y%m%C%Q!<HG$_$?$$$J46$8$G$7$?$M!#(B2.0
$B7ONs$O!"(B1.9$B$G$N6lFq$N(Bleap$B$r2L$?$7$?D>8e$@$1$K$&$^$/9T$-$9$.$F$$$k$H$$$&(B
$B$N$O$"$j$^$9!#(B

>
$B$3$l$,!"Ev=i$N#2!]#32s$N%j%j!<%9$O(BTEENY$B$"$2$k!#!J(BRuby$B%3%_%e%K%F%#$,(B99.9%$B$N%f!<%6$,Ho32$r<u$1$J$$$H9M$($k$h$&$J!K>.$5$JHs8_49$b$"$j$&$k!#$=$l0J9_$O%Q%C%A%l%Y%k$G(Bsymbol
>
$B:o=|J}8~$NHs8_49$O$J$7!#$H$+$@$C$?$iJ,$+$j$d$9$$$7!"%D!<%k;Y1g$b$7$d$9$$$N$G;?@.$7$d$9$$$G$9$M!#(B

$B?7$7$$%9%-!<%`$G$b(B TEENY=0 $B$/$i$$$O%W%l%S%e!<07$$$G(B TEENY=1
$B$GHs8_49$b(B
$B$"$k$h!"$H$$$&$N$b$$$$$+$b$7$l$^$;$s!#>/$J$/$H$b$I$3$+$i%a%s%F%J%s%9(B
$B%U%'!<%:$+!"Hs8_49$O$"$k$+!"$H$$$&;X?K$rFb30$K<($9$3$H$,Bg;v!#(B
02da662c083396641da96c1d32fc86ed?d=identicon&s=25 KOSAKI Motohiro (Guest)
on 2013-08-31 05:47
(Received via mailing list)
>>
$B$"$H!"(BRuby$B$N%/%i%9$O!V3+$$$F$$$k!W$N$G!"$I$s$J%P%0%U%#%C%/%9$G$"$C$F$b$"$d$7$2$J%b%s%-!<%Q%C%A%c!<$5$s$O$.$c$C$H$$$&%j%9%/$O$"$k$o$1$G!"$3$N%k!<%k$@$H%Q%C%A%l%Y%k$@$1$G$9$`%1!<%9$,$[$\L5$/$J$k$s$8$c$J$$$+$J$"!#(B
>
> $B%Q%C%A%l%Y%k$@$1$G:Q$^$J$$JQ99$r2C$($?>e$G$N%j%j!<%9$NM>CO$,(B9$B2s$"$l$P!"(B
> $B8=:_$N%j%j!<%9%5%$%/%k$r8+$k$K==J,$G$O$J$$$+$H$$$&$N$,<g;]$G$9!#(B

$B$A$g$C$H<+?H$,$J$+$C$?$N$G(B1.8.7$B$N%j%j!<%92s?t$rD4$Y$F$_$?$N$G$9$,(Bp0$B$H9g$o$;$F(B22$B2s(B
$B%j%j!<%9$,9T$o$l$F$$$^$9!#(B
$B$$$/$D$+$O%Q%C%A%l%Y%k$K=PMh$k$N$G$7$g$&$,!"(B9$B2s$"$l$P3Z>!$H$$$&%l%Y%k$+$H$$$&$H(B
$B$A$g$C$H<+?H$,;}$F$^$;$s$G$7$?!#(B

$BA02s$N%a!<%k$G=q$$$?$H$*$j!"(Bruby$B%l%Y%k$NJQ99$,#1$D$G$bF~$C$?$i(BTEENY$B$r(Bbump$B$7$J$$$H(B
$B$$$1$J$$Ds0F$K8+$($k$?$a$G$9!#(B

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


>
>>
$B3+H/?X$K$*$1$k(BABI$B8_49@-$K$D$$$F$N0U<1$O9b$^$C$F$$$k$H$$$&G'<1$K$b2{5?E*$G!"0U<1$7$F$$$k?M$O$7$F$$$k$7$7$F$$$J$$?M$OA4A3$7$F$$$J$$$N$G!"%a%s%F%J!<$NIi2Y$r8:$i$9$K$O%3%_%C%?!<$NA10U$@$1$G$O$@$a$G%D!<%k$N=u$1$,$$$k$H$$$&$N$,(B
>> ABI checker$BF3F~;~$N%P%C%/%0%i%&%s%I%b%A%Y!<%7%g%s$H$7$F$"$j$^$7$?!#(B
>
> $B$=$b$=$b8=:_(BAPI
version$B$H$$$&$N$,<B$O2?$NLr3d$b2L$?$7$F$$$J$$!J(B1.9$B$G$b(B
> 2.0$B$G$b(BTEENY$B$9$i>e$,$C$F$$$J$$$78eJ}8_49@-$bJ]$?$l$F$$$J$$!K>u67$G$9$,!"(B
> $B>/$J$/$H$bDI2C$d3HD%$,$"$k$N$G>e$2$k$Y$-!":o=|$dJQ99$,$"$k$N$G%P%C%/%]!<(B
> $B%HIT2D!"$H$$$&H=CG$,%D!<%k$N;Y1g$G$"$kDxEY%G%8%?%k$K$G$-$k$h$&$K$J$j$^(B
> $B$7$?!#(B

$B$=$&$G$9$M!#F10U$7$^$9(B

> $B%:$,$"$j$^$9!#(B
$BA4A3CN$i$J$$$N$G$9$,!"(Bgem$B$O%Q%C%A%l%Y%k$O%A%'%C%/$G$-$J$$$b$N!)(B


>> > $B1~$($k$b$N$G$9!#(B
>>
$B:o=|J}8~$NHs8_49$O$J$7!#$H$+$@$C$?$iJ,$+$j$d$9$$$7!"%D!<%k;Y1g$b$7$d$9$$$N$G;?@.$7$d$9$$$G$9$M!#(B
>
> $B?7$7$$%9%-!<%`$G$b(B TEENY=0 $B$/$i$$$O%W%l%S%e!<07$$$G(B TEENY=1
$B$GHs8_49$b(B
> $B$"$k$h!"$H$$$&$N$b$$$$$+$b$7$l$^$;$s!#>/$J$/$H$b$I$3$+$i%a%s%F%J%s%9(B
> $B%U%'!<%:$+!"Hs8_49$O$"$k$+!"$H$$$&;X?K$rFb30$K<($9$3$H$,Bg;v!#(B

$B$O$$!#:Y$+$$$H$3$m$G5$$K$J$k$H$3$m$O$"$j$^$9$,!"AmO@$H$7$F$O;?@.$G$9!#(B
9361878d459f1709feec780518946ee5?d=identicon&s=25 naruse (Yui NARUSE) (Guest)
on 2013-09-02 18:25
(Received via mailing list)
Issue #8835 has been updated by 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.
英語のチケットに日本語がぶら下がっていると英語しか読めない人から見て感じが悪いので、
そうしたいときには別に日本語のチケットを作ってそこからぶら下げるようにして下さい。
----------------------------------------
misc #8835: Introducing a semantic versioning scheme and branching
policy
https://bugs.ruby-lang.org/issues/8835#change-41543

Author: knu (Akinori MUSHA)
Status: Open
Priority: Normal
Assignee: knu (Akinori MUSHA)
Category: misc
Target version: current: 2.1.0


=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
233c279c012ebac792aaa805f966cbc7?d=identicon&s=25 steveklabnik (Steve Klabnik) (Guest)
on 2013-09-04 21:24
(Received via mailing list)
Issue #8835 has been updated by steveklabnik (Steve Klabnik).


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

I only know a very small amount of Japanese, but the Google Translate of
your post was very understandable.
----------------------------------------
misc #8835: Introducing a semantic versioning scheme and branching
policy
https://bugs.ruby-lang.org/issues/8835#change-41618

Author: knu (Akinori MUSHA)
Status: Open
Priority: Normal
Assignee: knu (Akinori MUSHA)
Category: misc
Target version: current: 2.1.0


=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
054b5f6b8afdd5f6190bad08e46cd782?d=identicon&s=25 zzak (Zachary Scott) (Guest)
on 2013-12-09 21:19
(Received via mailing list)
Issue #8835 has been updated by zzak (Zachary Scott).


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


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

Author: knu (Akinori MUSHA)
Status: Open
Priority: Normal
Assignee: knu (Akinori MUSHA)
Category: misc
Target version: current: 2.1.0


=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
054b5f6b8afdd5f6190bad08e46cd782?d=identicon&s=25 zzak (Zachary Scott) (Guest)
on 2013-12-17 23:44
(Received via mailing list)
Issue #8835 has been updated by zzak (Zachary Scott).


I have submitted announcement for semantic versioning scheme to
ruby-lang.org: https://github.com/ruby/www.ruby-lang.org/pull/468
----------------------------------------
misc #8835: Introducing a semantic versioning scheme and branching
policy
https://bugs.ruby-lang.org/issues/8835#change-43727

Author: knu (Akinori MUSHA)
Status: Open
Priority: Normal
Assignee: knu (Akinori MUSHA)
Category: misc
Target version: current: 2.1.0


=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
C4c327c418a3182b7f6a30dd1534143a?d=identicon&s=25 Vít Ondruch (vo_x)
on 2014-01-02 17:58
(Received via mailing list)
Issue #8835 has been updated by 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.
----------------------------------------
misc #8835: Introducing a semantic versioning scheme and branching
policy
https://bugs.ruby-lang.org/issues/8835#change-44020

Author: knu (Akinori MUSHA)
Status: Open
Priority: Normal
Assignee: knu (Akinori MUSHA)
Category: misc
Target version: 2.1.0


=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
E7cff3cfd41c495e1012227d7dc24202?d=identicon&s=25 Luis Lavena (luislavena)
on 2014-01-02 20:16
(Received via mailing list)
Issue #8835 has been updated by 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.

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

Author: knu (Akinori MUSHA)
Status: Open
Priority: Normal
Assignee: knu (Akinori MUSHA)
Category: misc
Target version: 2.1.0


=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
Eabad423977cfc6873b8f5df62b848a6?d=identicon&s=25 unknown (Guest)
on 2014-01-30 07:26
(Received via mailing list)
Issue #8835 has been updated by Hiroshi SHIBATA.

Target version changed from 2.1.0 to current: 2.2.0

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

* Author: Akinori MUSHA
* Status: Open
* Priority: Normal
* Assignee: Akinori MUSHA
* Category: misc
* Target version: current: 2.2.0
----------------------------------------
=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


---Files--------------------------------
noname (205 Bytes)
noname (205 Bytes)
Eabad423977cfc6873b8f5df62b848a6?d=identicon&s=25 unknown (Guest)
on 2014-08-12 05:35
(Received via mailing list)
Issue #8835 has been updated by 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-...

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

* Author: Akinori MUSHA
* Status: Closed
* Priority: Normal
* Assignee: Akinori MUSHA
* Category: misc
* Target version: current: 2.2.0
----------------------------------------
=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


---Files--------------------------------
noname (205 Bytes)
noname (205 Bytes)
This topic is locked and can not be replied to.