API更新の方針を考える

[Hiroshiba]

内容

APIの破壊的変更などを、どのような考え方で行っていくかのドキュメントを作りたいなと思っています。
破壊的変更を行う理由・頻度・流れなどを考えたいです。

関連Issue

• 新クラス設計API #370 (comment)

Pros 良くなる点

API変更時に考えることが少なくて済む

Cons 悪くなる点

取り決めが結構大変

その他

いろんな例や考え方があると思うので、気軽にコメントしてみてください！

[Hiroshiba]

自分の考え方をまとめてみます。

そもそもAPIを更新するのは、既存ユーザー・新規ユーザーにより良いものを作って欲しいため。
新しい機能の提供、使いづらい機能の改善など。
あるいはメンテコストを削減し、間接的により良い機能を提供しやすくするためなど。

破壊的変更を慎重に行う必要があるのは、既存ユーザーへの安全提供と、使うのをやめたいと思われないようにするため。
既存コードが予想外の動作をしないよう気をつけたり、破壊的変更の頻度を下げたりなど。

一般的なsemverアップデートの方針転機：
メジャーアップデートは破壊的変更をしても良い。
マイナーアップデートは機能追加しても良い。
パッチアップデートはバグ修正しても良い。
メジャーバージョン０の場合の方針は未定義っぽい？いかなる変更も起こりえる。

メジャーバージョン０のうちは、マイナーアップデートで破壊的変更をしても良いと思う。
その代わり頻度を半年に１回程度にしたい。
例えばタイポの修正などユーザーに利益の少ない破壊的変更はなるべく避けたいけど、この頻度ならユーザーも許してくれそう。

意見募集中です･････！

[Hiroshiba]

@windymelt さんからご意見いただいたので引用させていただきます！！

• 新クラス設計API #370 (comment)