Re: Release candidate for XEmacs 21.4.4 / my vacation

SY> What does concern me is that this Feature-Package[tm] would be SY> very version specific. I would insist that this package goes SY> out of its way to bend over backwards and jump through hoops SY> to test for the XEmacs version and to do the right thing SY> accordingly. It's pretty easy, actually. You load feature-update.el which simply requires every file in the package. SY> It would mean that if a new version of XEmacs is released that SY> still doesn't have the new "features" of the SY> Feature-Package[tm], then of course, the Feature-Package[tm] SY> will have to be updated as well. If the fixes are kept in separate files, this can be easily automated. And it's not really necessry, since feature-update.el does requires, not loads. SY> Otherwise all hell will break out on c.e.x and I'll start SY> getting hate email from disgruntled users. :-( That would never do. That's what I'm trying to prevent. :-) I don't know whether it would have been acceptable to Michael in the EFS case or not, but it would have made it possible to temporarily fix EFS without changing the package. The cost to Michael (AFAICT) would be the administrative cost of providing the fix symbol in future versions of EFS. The cost to our users would be (1) we'd have to require EFS in our update so we can overwrite the function definitions that need to be fixed and (2) very confusing breakage if somehow the non-working definitions got reloaded. I think that overhead and the slight risk of reloading would be worth it _for a temporary, but urgent, fix_ like that one. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."