thoughts about 21.5 [was: make mule-ucs compile with new ben-mule]

moved to xemacs-beta. Ben> in my opinion, the correct time to make changes that might Ben> cause breakage is *exactly* when the core is at its most Ben> unstable. In the core, yes. Not in packages that have to remain compatible with earlier versions of XEmacs. If the core changes break stable packages, it's the core's problem until it gets promoted to gamma at least. Anything else is screwing the users. Ben> there is indeed one other place where sisheng comes up, which Ben> is in vm-vars; and there's one place where chinese-sisheng Ben> comes up, which is in ps-mule. Ben> perhaps we should provide an alias; but we didn't do that Ben> previously in the massive charset renaming, and things worked Ben> themselves out. I'll talk to Kyle about it, and we'll figure out what to do in ps-mule. Ben> i'm also feeling like the next release should be called 22.0. I've been assuming this, for basically the same reasons. Ben> it's been about the right length of time [4 years] and we Ben> have some major new stuff on the mule side, and there are Ben> some changes i'd like to make that might not be completely Ben> backward compatible, since keeping backward compatibility Ben> either would inhibit the changes completely or just create Ben> incredible amounts of mess. that way our hand would be freed Ben> somewhat w.r.t. reasonable user-interface changes. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.