Teeda のバージョニングについて整理

　↑こちらのコメント欄か込んできたのでちょっと整理します。

　まず、この一連の流れで私が感じたことを率直に挙げます。ここでは仮にバージョンが 1.2.3 だとすると、1をメジャーバージョン、2をマイナーバージョン、3をリビジョンと呼ぶことにします。

メジャーバージョン、マイナーバージョン、リビジョンのそれぞれの役割がよくわからない。
- どういうときにそれぞれの数が増えるのか。少なくとも今はリリースごとにリビジョンがあがり、メジャーバージョンやマイナーバージョンは「気分」で上がってるような気がする（私個人的にはそう見える）。
- バージョンは「ただの記号」だとはいえ、「プロジェクト」と呼ばれるもので使用されているのだから何かしらの指針があるはず。
βやRCが何のためにあるのかわからない。
- Teeda は「素早くリリースしてフィードバックを得ながら完成度を高めていくという開発スタイル」なのは私個人的には理解できる。しかし、そういうスタイルのものは開発版やβ版に位置づけるものではないか？
  - たとえば、私とてしては「素早くリリースしてフィードバックを得ながら完成度を高めていくという開発スタイル」ならばこのようにしてはどうかと思う。マイナーバージョンを奇数のものを開発版とし、Teeda 1.0.0 リリース後、1.0.1、1.0.2……と行くのではなく1.1.0、1.1.1……と進む。この開発版に特にフィードバックをもらうようにする。安定版は互換性を大して損なわない機能をバックポートしたりバグフィックスで 1.0.1 や 1.0.2 をリリースする。開発版が煮詰まってきたら 1.2.0 としてリリースする。
「素早くリリースしてフィードバックを得ながら完成度を高めていくという開発スタイル」なのにβ版や開発版を明確に別けないのはある種の「ユーザだまし」というのは言い過ぎかもしれないけど少なくとも誤解を与えるのではないか。「安定版」といわれたら額面どおり「安定している」と「ふつうの」ユーザなら感じると思う。その安定とは動作もそうだが、互換性もある程度は期待を持っているはず。
私個人的には OSS プロジェクトは、開発者の「モチベーション維持」が重要なのは理解している。
- そのモチベーション維持のためには、「イケてない」実装だったと悔やんだらこの世からとっとと取り払ってしまうことが重要だということも理解している。
  - なので、実装上の互換性はもとより仕様上の互換性が多少損なわれたとしても私の「開発者」としての立場では口で言うほど（ブログエントリに書いているほど）気にしてない。
  - しかし、採用するプロダクトを選定するリーダとしての立場では気になる。

　Teeda は「素早くリリースしてフィードバックを得ながら完成度を高めていくという開発スタイル」なのはいいが、一体誰に向かって発信してるかということですね。私が元記事で出した Teeda 1.0.2 のころは Teeda はキャズムの向こう側の先を行ってて、Struts などの巨人フレームワークに比べたら、屁みたいなユーザ数だったでしょう。なので、安定版と開発版なんて分けてユーザを分断させたら大したフィードバックも得られないのかなとも思います。

　しかし、リリースサイクルが短いといわゆる「置いてけぼり」を食い易くなります。ちょっと目を放した隙にリビジョンが何個も違ってしまったりするわけですね。Teeda ばかり使っているわけではない現場は少なくないと思いますので、こういうことはよくあることでしょう。するとクラス消失はやっぱり怖いです。このあたりは「移行ガイド」がわかりやすいところにあれば良いなと思う次第です。

　「ないものは作れ」という OSS 精神からすると、私ががんばれば良いのか？！