Skip to end of metadata
Go to start of metadata

目次

ロール

いろいろ話をしていて「誰にとっての機能」という話が混乱するので、用語を下記に統一する。

  • コミッタ (committer)
  • 拡張開発者 (extender)
    • 用意された拡張メカニズムを用いて、Jiemamyを拡張する開発者。要するに dialect, composer のコミッタ + サードパーティ製 dialect, composer の開発者
  • APIユーザ (API-user)
    • Jiemamyをライブラリとして利用する開発者。要するに hestia, eros コミッタ + Jiemamy APIを使用したサードパーティ製アプリケーション・フレームワーク等の開発者
  • hestiaユーザ (hestia-user)
    • Jiemamyをhestia, eros経由で使用するユーザ。

上記の順で「以上」「以下」という表現も用いる。

  • APIユーザ以下 = APIユーザ + hestiaユーザ
  • 拡張開発者以上 = 拡張開発者 + コミッタ

バグ基準

APIがJavadocに記述されない動きをした場合はすべてバグとする。メソッドの動きはJavadocに説明されていなければならない。

  • バグには「仕様バグ」(Javadoc自体の記述漏れ・不整合など)と「実装バグ」(コードの不整合など)がありえる。
  • Javadocの @throws は RuntimeException についても記述されていなければならない。
    • つまり、Javadocに記述のない例外(RuntimeExceptionを含む)が飛んだら、バグである。
  • JiemamyのAPIは NullPointerException をスローしない。NullPointerExceptionが飛んだらバグである。
    • throw new NullPointerException(...); は使用しない。代わりに IllegalArgumentException を使用する。

Jiemamy core API群(artemis)

  • 実装コンポーネント(artemis)のバージョニングは、major.minor.release[-SNAPSHOT] とする。
  • majorは大なアーキテクチャの変更があった際に繰り上げる。
  • minorは、仕様に変更があった際に繰り上げる。(つまり、zeusに対するあらゆる変更で繰り上げる)
  • 仕様に変更がなく、実装のみを修正(bug fix等)した場合に、releaseを繰り上げる。

仕様として一度リリースしたAPI(型, メソッド等)の扱いについては、以下の通りとする。

  • API追加は、随時行う。
  • API廃止は、@Deprecated アノテーションで対処する。
    • 時機を見て削除を行う。v1.0以前は2~3ヶ月、v1.0以降は未定(もしかしたらメジャーバージョンアップまで消さない、とするかも)
  • API変更について
  • メソッドのシグネチャが変わる場合は、旧メソッドを @Deprecated とし、新メソッドをオーバーロード状態とする。
    *シグネチャの変更を伴わない変更(挙動の変更=Javadocの変更)は、v1.0以前は随時行う。v1.0以降はどうするか検討中。

モデルエディタEclipseプラグイン(hestia)

  • Eclipseコンポーネント(hestia)のバージョニングは、major.minor.release.qualifier とする。
  • major, minorは、準拠する対象APIバージョンに合わせる。(v0.3.1準拠の場合は、v0.3.1)
  • qualifierは、ビルドのタイムスタンプとする。

CLIクライアント(eros)

(ATDK)


null
Labels
  • None