Skip to content

Instantly share code, notes, and snippets.

@hsbt hsbt/gist:7719305
Last active Dec 29, 2015

Embed
What would you like to do?

2.1 以降のバージョンの付け方の提案

基本方針: Semantic Versioningに寄せる

今後の呼び方 ruby-{MAJOR}.{MINOR}.{TEENY}

  • MAJOR: 特に互換性が無い変更、MINOR として出せないような大きい変更が入った時に上げてリリース
  • MINOR: API 互換を保証しない変更、毎年12月25日に上げてリリース
  • TEENY: API 互換を保つように努力する変更、上記二つに当てはまらない時に上げてリリース
  • PATCHLEVEL: コミットごとの数字、MINORを上げた時に0にする

knu さんの案と違うところは、TEENYが上がっても PATCHLEVEL を0に戻さずにひたすら上げ続けます。bugs にある n0kada さんの案と同じで PATCHLEVEL だけ残すという違いです。

http://d.hatena.ne.jp/nurse/20131111#1384136384 の 1 + 2 が TEENY, 3 + 4 が MINOR, 5 が MAJOR という扱いです。

TEENYが10を超えそうになったら、10に上げます。ある {MAJOR}_{MINOR} バージョンのメンテナンス期間を2年と見込んで、リリースサイクルは2-3ヶ月の1回くらいにコントロールしていきます。(定期リリースではない)

ブランチの作り方

  • trunk
  • ruby_{MAJOR}_{MINOR}

上記の二種類のみとします。TEENY のリリースを行っても ruby_{MAJOR}_{MINOR} のまま使い続けます。タグは打ちます。

ABI バージョン

  • {MAJOR}.{MINOR}.0

APIの互換性は崩れないように努力する前提なので teeny を 0 固定にします

メリット

TEENY を上げることで、アップデートのロビーイング効果を高めることができます。特にホスティング業界や保守的な業界の場合、2.0.0 というバージョンを採用することに消極なことがあり、2.0.1 と出すことで Ruby のパッチレベル運用について改めて説明する必要なく採用を進めることができます。

@sorah

This comment has been minimized.

Copy link

commented Dec 5, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.