sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: Every time a xemacs-package maintainer wants to sync a package with the external source, it needs to update any XEmacs modifications. Over time, the modifications and addition of code to cater for broken stuff in older XEmacses only grows, and it becomes more and more likely that bugs are due to these modifications. Bit-rot will happen because a maintainer either has to test the code with every flavor of XEmacs (version, mule or no mule, file coding or no file coding, etc) or just incorporate the old modifications without testing them. If the external developer can be persuaded to maintain backwards-compatibilty himself, then good, but there will be a hard break sometime (like when Gnus stopped supporting emacs 19). Either 1) The XEmacs package maintainer adds the backwards compatibility into the package. (I wouldn't want to be the Gnus XEmacs-package maintainer when Gnus stops supporting XEmacs 21...) 2) Older XEmacses are required to download a compatibility library (APEL?) in order to use newer packages. 3) Older XEmacses simply can't use some newer packages. (OK by me, I don't see many complains about emacs 18 code not running in XEmacs 21.4.) Just my $.02...

Simon> Every time a xemacs-package maintainer wants to sync a Simon> package with the external source, it needs to update any Simon> XEmacs modifications. Yes. We have a choice. We can be professionals, and attempt to do real maintenance, or we can be prima donnas, assuming that we have no responsibility to people who don't update to our latest version of XEmacs. Since the BTS still shows plenty of reports coming in for versions as old as 19.12, that assumption is purely self-serving. That said, there has been discussion off and on of improving versioning in the package system. If you want to add to that discussion, especially in the form of code ;-), many folks will be eternally[1] grateful. The consesnsus seems to be be that the best way to deal with it is to test for a needed feature, and provide your own new feature only if the dependency is available. Ie, basically the strategy Michael is recommending. Simon> 3) Older XEmacses simply can't use some newer packages. (OK Simon> by me, I don't see many complains about emacs 18 code not Simon> running in XEmacs 21.4.) That's because we flame those who worry about it out loud. :-( Footnotes: [1] That is, until something with your code in it breaks :^) -- 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."