[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: Re: Possible help with stable Emacs releases.]

From: Kim F. Storm
Subject: Re: address@hidden: Re: Possible help with stable Emacs releases.]
Date: Tue, 05 Oct 2004 10:34:23 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

Rob Browning <address@hidden> writes:

> Francesco Potorti` <address@hidden> writes:
>> While I want to make clear once again that this is a separate issue,
>> which is completely independent from the previous one, yes, I agree
>> that clearly indicating which releases are bugfix-only and which are
>> not would be valuable.
> Actually now that I think about it, at least for those packaging
> Emacs, it's somewhat critical.  Right now Debian pacakges Emacs as
> emacsXY where XY is the major number (i.e. emacs19, emacs21, etc.).
> This is done under the assumption that only a change in XY signals the
> potential for major breakage.
> The Debian Emacs Policy is set up based on that assumption so that we
> can have multiple major versions of Emacs installed without breakage.
> This was very important back during the transition from emacs19 to
> emacs20 because there were many users who had code that they couldn't
> afford to port immediately.  It can also be important because it may
> take a while for all of Debian's Emacs sub-packages (calc, bbdb, gnus,
> psgml, ...) to be updated to work with the new major version of Emacs.

IIRC, 20.6 -> 20.7 was a pretty major update.

> (In part, the Debian policy arranges things so that a given add-on
>  package can tell which Emacs "flavor" it's being installed for, and
>  can make decisions based on that if necessary.)
> If Emacs ever had a nominal minor release that was really a major
> release (which was significantly incompatible in some way), it could
> cause a painful transition.

I know for sure that there are things in CVS emacs that breaks code
which run ok on 21.3.  Specifically this change has caused problems:

** `split-string' now includes null substrings in the returned list if
the optional argument SEPARATORS is non-nil and there are matches for
SEPARATORS at the beginning or end of the string.  If SEPARATORS is
nil, or if the new optional third argument OMIT-NULLS is non-nil, all
empty matches are omitted from the returned list.

This could be another argument for using 22.1 for the next release.

Another example is the version of cua-mode that I distribute from my
own web-site.  It works fine with 21.3, but it does not run on CVS
emacs due to changes in key parsing.

Instead a cua-mode specifically developed for CVS emacs is included
with CVS emacs, and the user _must_ remove the old cua-mode
installation from the load path before using the one included with CVS

I suppose there may be other cases like that, as CVS emacs include
quite a number of new packages.

Kim F. Storm <address@hidden> http://www.cua.dk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]