Why multiple Emacs flavours?

Rob Browning rlb@defaultvalue.org
Sat, 18 Jun 2005 15:42:15 -0500


J=E9r=F4me Marant <jmarant@free.fr> writes:

> I recently asked myself why we need to ship different flavours for
> Emacs like "emacs20", "emacs21", and so on?  Why not simply support
> one "emacs" flavour per Emacs release?  (I'm asking because I don't
> have the emacs background in Debian).

Sure.

Well, I think the easiest way to explain the original rationale is to
think about the fact that Emacs has a fairly large installed user
base, and a lot of add-on packages, and we don't really have any
control over when/if the upstream might break backward compatibility
with a major release (for example if they break backward compatibility
with .elc files, as they have in the past).

If we don't support multiple flavors of emacs, then we force everyone
to upgrade as soon as the new version comes out.  At least back during
the emacs19 to emacs20 transition, this was perceived by many users as
a *huge* problem.  Many of them had (or claimed to have) a lot of
existing software which wasn't compatible with emacs20, and which
couldn't easily be ported (and it might be that some add-on packages
were never ported).  Further, emacs20 was claimed to be much more
resource intensive, and a big burden on some of the hardware available
at the time (see the Mule controversy, etc.).

Supporting both emacs19 and emacs20 for a while gave those people for
whom the transition was a problem more time to accomodate the changes,
and it wasn't nearly as much work for us as it might have been since
we already needed the emacsen-common infrastructure in order to be
able to handle both emacs and xemacs.

OTOH, supporting more than one flavor *is* more work, but in cases
like emacs20 -> emacs21, where the upstream changes aren't nearly as
substantial as they were during emacs19 -> emacs20, the need to
support two flavors for any appreciable amount of time is much lower.
i.e. the point at which I can start tagging bugs as "wontfix ->
upgrade to emacsN+1 is be much sooner.

Also, even if we don't provide extremely active support for the older
flavors, they still allow users who don't want to fully upgrade
immediately, but want to be able to try the newer emacs, an easy way
to do so.

Hope this helps.

--=20
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 =3D 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 7=
3A4