scalaとか・・・

Scalaでバイナリ互換を維持しながらのプロジェクト運営

scala, scalaz, json4s | 00:47 |

json4sでせらさんが頑張ってくれるらしいけど、どこにも(たぶん英語でも)まとまった知見ないはずなので、とりあえずscalazの知見をもとに、まとめておく

• 最新開発版のbranchをつくってそちらをメインにしておく
  • それ以外のやり方もありえる(scala本体)が、たぶん開発版(バイナリ互換維持しないほう)をメインにしておいたほうがよい。
  • 具体的には、json4s 3.3ブランチがバイナリ互換維持するなら、3.4か4.0ブランチを作っておく
  • scalazだったら、これ書いてる現在 series/7.2.x が開発用 series7.1.x がバイナリ互換維持しつつメンテする用

• 上記のbranch戦略をREADMEか何かに書いておき、pull reqは基本的には開発branchのみで受け付ける(両方で無造作に受け付けるとややこしくなるので)
  • 万が一、間違って互換維持するほうのbranchで、「新規機能追加などの本来開発用branchでmergeすべきpull req」を受け付けてmergeしまったら、即座に開発用のbranchにもcherry-pickする(もしくはrevert？)などの対策が必要(?)

• 互換維持するほうのbranch
  • mimaをtravisで自動実行するようにしておく(json4sは既になっている)
  • mimaのpreviousArtifactの正しい設定
    • もし3.3.1を出して、3.3.2の開発がはじまった際には、previousArtifactは必ず3.3.1にしておかなければならない
    • なぜなら、3.3.0から3.3.1で追加したメソッドを3.3.2で消したり変更しても、(previousArtifactを3.3.0のままにしておくと)気が付かないからである
    • それで、そのpreviousArtifactの変更は絶対忘れやすいので、sbt-release pluginなどと組み合わせて自動化するのが望ましい(scalazはそうしてる)
  • READMEのバックポート面倒になってくるので「最新版のほうのREADMEを見ろ」と、ほぼ一言だけのREAMEにしておくのもあり？(色々面倒になった結果scalazはそうした)

• 互換維持しない開発用branch
  • mimaの設定は無効にしておく
  • あと何かすることあったっけ・・・？

• バックポートする際の方針、やり方
  • 丁寧にやるならREADMEか何かに書いておく？
  • そもそもどういうコミットをバックポートするのかコミッターで話し合ってなんとなく決めておく？
  • その都度話し合う？
  • みんなが興味なさそうなら、勝手にだれか一人がバックポートする(現状のscalaz)
  • 都度バックポートするのか、新しいversion(たとえば3.3.1)出す際にまとめてバックポートするのか？の方針(scalazは最近はなんとなく後者)

• 既存の3.3向けのpull reqどうなるのか？
  • githubでは、pull reqのmerge先のbranch変更は、たしか出し直す以外不可能？
  • バイナリ互換ないpull reqは「ごめん、こういう方針になったから3.4(or 4.0)のブランチにpull req出し直してくれ？」と言いつつpull req閉じて回る必要あり？
  • メインのブランチが変わるのは、scalazでも、1、2年に1回しかないことなので、どうなるか(どうしたか)覚えてない。実はこれ以外の方法があるのか自信ない
  • といっても、openのままのpull reqは、今回のjson4sの場合少ないから、あまり問題ないかも

• このあたりのことを
  • そもそもこれで全部網羅したかあやしい・・・？けど、たぶん大体書いたはず
  • で、せらさんが全部頑張る
  • 自分がpull reqする or コミット権限もらって(もうそろそろもらってもいいんじゃね？)手伝う
  • その前に、そもそもこんな感じの方針でいいのか他のコミッターに確認とる？別にいらない？

これほんとは全部英語で書いてjson4sのissue欄で議論開始すべきなのだろうけど、まぁ一旦日本語でblogに・・・。

とりあえず、最低限早めに必要であろう件を箇条書きにしたissueは作った

https://github.com/json4s/json4s/issues/306

ツイートする