>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)iskon.hr> writes:
Hrvoje> Adrian Aichner <aichner(a)ecf.teradyne.com> writes:
> Doing it right (following Kyle's suggestion) would in this
> particular case lead to awkward code bloat compared to the version
> before Yoshiki's patch. The new feature of `completing-read', the
> DEFAULT argument, cannot be relied upon (because XEmacs-21.1.8 does
> not have it).
Hrvoje> Sorry, I don't agree with "cannot be relied upon" part.
Hrvoje> Backward compatibility is a nice thing, but can't we just
Hrvoje> have the new version of the package support the new
Hrvoje> XEmacs?
Forcing people who have and latest released and the latest beta XEmacs
installed to maintain two separate XEmacs packages trees manually?
Shudder!
Hrvoje> I dislike the idea of our packages avoiding using our new
Hrvoje> features because of compatibility with old XEmacsen that
Hrvoje> need to be run with these very same packages. If the
Hrvoje> package system can't new packages requiring new features,
Hrvoje> then the package system needs fixing.
I agree. Packages were separates from XEmacs to ease their evolution,
right? Having them tied to a particular XEmacs is bad. Tying them to
an API version (of core lisp functionality) might be feasible.
Is the standards-version field of the `package-get-base''s plist
intended to be used to track API changes?
Using it one could implement functionality which allows to
"download latest package of API standards-version 1.1"
or
"download latest package of API standards-version 1.2"
What if the standards-version where to track the XEmacs release version?
Like so
"download latest package of XEmacs standards-version 21.1"
or
"download latest package of XEmacs standards-version 21.2"
We would still need two separate package trees, but at least
maintaining them would be easy.
Actually we would need a package tree per standards-version, not
necessarily per XEmacs.
What do you think?
Adrian