Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> I wouldn't be opposed to making exceptions on a case-by-case basis
> for packages that have never worked with 21.4.
Well for modes that never was in 21.4 that might be Ok but it would be
sad to see more and more packages barf about wrong XEmacs
version.
I really don't think there would be that many. Look at how few
packages are in mule-packages, and that's a really serious
incompatibility.
> However, most features can easily be supported for 21.4 in
Lisp.
This works for compatibility hacks. Maybe that is possible, I don't
know. I suspect it can be quite difficult to work around all API
differences this way but that is yet to prove of course.
APEL has been doing it for two decades. APEL's approach is possibly
unacceptable in our packages (choice of underlying API is done at
compile-time for efficiency, and therefore "bakes it in" to the
compiled code, making it inefficient for more recent XEmacsen and
unusable for older ones), but it shows that it can be done. Our
problem would be less difficult than APEL's as well, since we only
need to target the most recent 21.4, which is a very stable API.
It is also a question if package maintainers are willing to do all
that. I guess not. We can be happy if we get some maintainers to merge
packages for 21.5.
Once Mike gets the packages into Mercurial, we can maintain local
branches of externally-maintained packages much more easily. Of
course we'd want the external maintainer's agreement in principle, but
who does the work and how it's done (ie, in-package or with a separate
compatibility layer) would be negotiable.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta