APEL-Diet: Road to APEL-Lite (Re: *.elc compatibility between mule and nomule)

[Yuuichi Teranishi]

At 17 Jun 2003 18:53:00 +0900,
Shuhei KOBAYASHI wrote:
> 
> 誤解されたかもしれませんが, 私は「移動」とは書いていなかったはずです.
> 様々な方面の要求を満たすために, luna を cvs の module 的に独立させて,
> FLIM の他に APEL にも含めるのはどうかと考えていました.

(FLIM と APEL の両方に luna を含めるのは、やめたほうがいいと思いますが、
 その議論はここではしないということで…。)

>     code の移動を行なうと backport が面倒になりそうなので「削る」だけ.

これは、つまり、Old Emacsen 対応をなくすことで、
* すべての内容が不要となるファイルは削除する
* 一部でも内容が残るファイルは削除しない
という風にするということでしょうか。
で、そうすると、変更点があっても APEL 19 (仮称)や apel-10-maintainance など
へ反映しやすいので、そうしたほうがよい、ということですね。

>     pcustom.el は
> 
>       ;; If you really want to make your software available to pre-"custom"
>       ;; Emacs (v18 or v19), put (require 'pcustom) in your software.
>       ;; Otherwise, use (require 'custom) instead.
>       (require 'custom)
>       (provide 'pcustom)
> 
>     のような形で残さなければいけない.

これは、つまり、従来の APEL アプリケーションは変更しなくて済むことが前提、
(API は変更しない) ということでしょうか。

> > >     a. APEL 11: APEL 10 の次だから.
> > >     b. APEL 20: Emacs 20 以上を対象とするから.
> > >     c. APEL 21: Emacs 21 API を提供するから.
> > やっぱり、この中では b. がわかりやすいかな…。
> 
> 実は APEL 19 と APEL 20 には分けない方向に傾いた時点で私は a. が良いと
> 思っています.  b. や c. のような規則を設けても次の major version up で
> すぐに破綻してしまいそうなので.

APEL 19 の可能性を完全になくすわけでもないと思われるので、
APEL 20 でいいんじゃないかなあ、と思いますが、
べつになんでもいいと思います。

--
Yuuichi Teranishi (寺西裕一) <teranisi ＠ gohome.org>
GPG Public Key: http://www.gohome.org/gpg/teranisi.asc
"There will be an answer, let it be..."