[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
emacs.
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
- Re: address@hidden: Re: Possible help with stable Emacs releases.], Francesco Potorti`, 2004/10/01
- Re: address@hidden: Re: Possible help with stable Emacs releases.], Rob Browning, 2004/10/04
- Re: address@hidden: Re: Possible help with stable Emacs releases.],
Kim F. Storm <=
- Re: address@hidden: Re: Possible help with stable Emacs releases.], Rob Browning, 2004/10/05
- Re: address@hidden: Re: Possible help with stable Emacs releases.], Juri Linkov, 2004/10/05
- Re: address@hidden: Re: Possible help with stable Emacs releases.], Rob Browning, 2004/10/05
- Re: address@hidden: Re: Possible help with stable Emacs releases.], Stefan Monnier, 2004/10/05
- Re: address@hidden: Re: Possible help with stable Emacs releases.], Kim F. Storm, 2004/10/06
Re: address@hidden: Re: Possible help with stable Emacs releases.], Stefan, 2004/10/05
Re: address@hidden: Re: Possible help with stable Emacs releases.], Rob Browning, 2004/10/05