Re: package system and backwards compatibility
sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
Simon> If packages aren't allowed to use new functionality in
XEmacs,
Simon> the bit-rot of xemacs-packages will only increase and
Simon> maintainance will be a nightmare.
I don't see how this introduces bit-rot. Maintenance gets slightly
harder, but if it gets excessive, just abstract out the relevant code
into a separate file. History has shown that this approach is not too
expensive to keep up.
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...