Translation from https://gist.github.com/hsbt/7719305
ruby-{MAJOR}.{MINOR}.{TEENY}
- MAJOR: Increase when incompatible change (or some changes can't be releaed as MINOR) happened
- MINOR: Increase at each December 25th; may be API incompatible
- TEENY: Increase if doesn't match above 2 conditions; try to keep API compatibility
- PATCHLEVEL: number of commits since last MINOR release (will be reset at 0 when releasing MINOR)
Difference from knu's idea is: PATCHLEVEL keeps value across TEENY releases. Same with n0kada-san's idea in bugs.r-l.o.
In the expected user needs written in http://d.hatena.ne.jp/nurse/20131111#1384136384,
- Give me only security fixes (such as debian and heroku)
- Give me only bug and security fixes (normal Ruby users)
- Give me bug and security fixes, and some tiny new features and improvements (advanced users)
- Give me almost compatible (super advanced users)
- Don't care any compatibilities. (Ruby committers?)
TEENY releases satisfy (1) and (2). MINOR satisfies (3) and (4), and MAJOR satisfy (5).
We increase TEENY even if it'll be over 10. Assuming a {MAJOR}_{MINOR} version's maintaining term is about 2 years, we'll controll release cycle to be each 2 or 3 months. (note that this doesn't mean we don't release periodically)
- trunk
- {MAJOR}_{MINOR}
We keep the above 2 branches. Keep using same {MAJOR}_{MINOR} branch across TEENY releases.
We add tags for each all releases.
{MAJOR}.{MINOR}.0
We try to keep ABI compatibility among same {MAJOR}_{MINOR} release, so TEENY is fixed at 0.
TEENY を上げることで、アップデートのロビーイング効果を高めることができます。特にホスティング業界や保守的な業界の場合、2.0.0 というバージョンを採用することに消極なことがあり、2.0.1 と出すことで Ruby のパッチレベル運用について改めて説明する必要なく採用を進めることができます。
Hugely in favor of this move. Would love to see it happen. 👍