FW: [Richard Stallman] Emacs 22.1 released

[Giorgos Keramidas]

Hi all,

As you can see in the following quote, Richard Stallman has announced
the much anticipated Emacs 22 release.

% Date: Sun, 03 Jun 2007 20:17:24 -0400
% From: Richard Stallman <rms at gnu.org>
% To: info-gnu-emacs at gnu.org
% Subject: Emacs 22.1 released
% Message-ID: <mailman.1548.1180925943.32220.info-gnu-emacs at gnu.org>
% 
% GNU Emacs 22.1 has been released.  It is available on the GNU ftp
% sites at ftp.gnu.org/gnu/emacs/ and its mirrors (see
% http://www.gnu.org/order/ftp.html).
% 
% The MD5 check-sum is the following:
% 
%     6949df37caec2d7a2e0eee3f1b422726  emacs-22.1.tar.gz
% 
% Please send any bug reports to bug-gnu-emacs at gnu.org.  You can use the
% function M-x report-emacs-bug to do this.

This release has been in the works several years, and we already have a
port which builds pre-release snapshots of GNU Emacs 22 in our Ports
tree (this is the editors/emacs-devel port).

I've been maintaining on and off the editors/emacs-devel port for some
time, with the kind help of many people who submitted PRs and/or even
wholesale updates to newer pre-release snapshots, but I don't know if I
am sufficiently experienced with the Ports tree to maintain _the_
official editors/emacs port.

Bearing this in mind, what is the usual way we like handling upgrades of
this sort or magnitude for our Emacs-depending ports?

Should we keep the editors/emacs-devel port, update it to Emacs 22.1 and
allow for some time of 'settling in' before we switch editors/emacs to
the 22.1 version?

Then when the time comes to switch editors/emacs to editors/emacs21 how
should we handle the 'move' (i.e. do we repo-move the files?)?

If we do the repo-move, what is the process of making sure all the Ports
which depend on editors/emacs21 keep working, and how do we handle ports
which use editors/emacs (emacs22 by then)?

With these questions in mind, I will be glad and grateful for any
insight you can offer, so that we can handle the transition to Emacs
22.1 as smoothly as possible, and with the least amount of problems for
our end-users :-)

Regards,
Giorgos