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

scala scalaz json4s

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


追記: