Andy Piper <andy(a)xemacs.org> writes:
How many packages are actually likely to get feature creep that is
backwardsly incompatible?
Basically every package that attempts to use a new feature that we
advertise. Also, every package that attempts to use functionality
that used to crash, but is now fixed.
Of course, this excludes packages that try to be compatible with
multiple XEmacs versions, but there is code that just tries to support
the latest XEmacs, whose authors don't feel like supporting everything
(some of them might not have access to old XEmacs versions).
I can't imagine that things like vm, gnus etc will since they
have
to support multiple emacsen already. It seems to me you could pick a
small subset (mule-base, xemacs-base?) of packages that you want to
tie to a specific major number whilst letting the others freefall.
If we implement that, I think the decision should be in the hands of
the actual maintainer.