Emacs release procedure (Was: [h-e-w] Current word on binaries)

Emacs release procedure (Was: [h-e-w] Current word on binaries)

[Eli Zaretskii]

Here's a message sent in the past by Gerd Moellmann in which he
summarized the procedure he used for making a pretest/release
tarballs.  Note that the specific versions and tags mentioned may need
to be revised/modified for each specific release.

Francesco, if you have any comments based on your experience of
releasing v21.3, please do.

One issue I remember from my experience is that there are directories
present in the checked-out branch, such as lispref, which should not
be in the tarball.  They are there because they are present on the
trunk and because the RC branch tag exists on those directories as
well.  The solution is either to remove the directories in your local
sandbox, or (better) remove the branch tags from the files that are
not supposed to exist on the branch, and use "cvs update -P" to let
CVS prune empty directories when the tree is checked out.

I'm cc'ing emacs-devel so that this procedure is archived and could
be useful to future release managers.  I started a new thread for the
same reason.

------- Start of forwarded message -------
Subject: CVS tags
Reply-To: gerd@gnu.org
From: gerd.moellmann@t-online.de (Gerd Moellmann)
Date: 24 Mar 2002 20:42:06 +0100
X-Sender: 520015515780-0001@t-dialin.net
X-Status: A

I see in the change logs that 21.2 has been released.

Since there is no CVS tag for it, I wonder if I ever told that I did
tag the releases and pretests to facilitate diffing etc., or if I did
tell how I built the releases and pretests.  In case it's useful,
below is the exact procedure I followed.

1. cvs update

2. Run admin/build-configs to make sure Emacs builds in a number of
   frequently used configurations.  Fix bugs.

3. Bootstrap to make 100% sure all elc files are up-to-date, and to
   make sure that the later tagged version will bootstrap, should it
   be necessary to check it out.

4. Commit loaddefs.el, cus-load.el, finder-inf.el.

5. Run autoconf, commit configure.

5a. For a release, add released change log entries, and set the
   version number (M-x load-file RET admin/admin.el RET, then
   M-x add-release-logs RET, and M-x set-version RET).

6. make-dist --snapshot.  Check the contents of the new tar with 
   admin/diff-tar-files against an older tar file.

7. Make xdeltas

8. Untar the tar files made in 6, configure, build, install, saving
   the output of these phases with the script command.  Check the
   output, esp. check that Info files aren't built.  (Saving 
   the output of the last release diffing helps spotting problems.)

9. `cvs tag EMACS_PRETEST_21_0_105' in the toplevel Emacs dir.
   (I used `EMACS_21_1' for the release tag.)

10. Increment version numbers in versions.el, README, emacs.texi.
  (See 5a).

11. Upload & announce.
------- End of forwarded message -------

Re: [h-e-w] Current word on binaries (EMACS_21_1_RC on cygwin)

[Harald Maier]

Jason Rumney <jasonr@gnu.org> writes:

> Harald Maier <harald@maierh.de> writes:
>
>> I am not sure if I took the right version (EMACS_21_1_RC), but if this
>> is the current RC branch, then the patch for the discussed problem is
>> _not_ in the branch.
>
> The fix has been committed to EMACS_21_1_RC now, so a cvs update
> should pick it up.

Hallo Jason,

I took the changes and all works fine if emacs is compiled with no
optimizations (--no-opt). If I turn on optimizations then I get the
following re-producable errors. The most time I am using --no-opt, so
that's the reason why it worked for me before. Have you or others an
idea how to verify or debug the problem? I still have here also a MSVC
and a two year old MINGW runtime environment with that I can do some
debugging. Building emacs on that environments still works fine.

Harald

Loading help...
Loading international/mule-cmds...
Loading case-table...
Loading international/utf-8...
Loading international/utf-16...
Loading international/characters...
End of file during parsing: g:/cvs/emacs-cygwin/lisp/international/characters.elc
Signal 127
make.exe[1]: *** [oo-spd/i386/emacs.exe] Error 255
make.exe[1]: Leaving directory `g:/cvs/rc/emacs-cygwin/src'
d:\usr\mingw-make\bin\make.exe: *** [all-other-dirs-gmake] Error 2

Re: [h-e-w] Current word on binaries (EMACS_21_1_RC on cygwin)

[Harald Maier]

Harald Maier <harald@maierh.de> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> Harald Maier <harald@maierh.de> writes:
>>
>>> I am not sure if I took the right version (EMACS_21_1_RC), but if this
>>> is the current RC branch, then the patch for the discussed problem is
>>> _not_ in the branch.
>>
>> The fix has been committed to EMACS_21_1_RC now, so a cvs update
>> should pick it up.
>
> Hallo Jason,
>
> I took the changes and all works fine if emacs is compiled with no
> optimizations (--no-opt). If I turn on optimizations then I get the
> following re-producable errors. The most time I am using --no-opt, so
> that's the reason why it worked for me before. Have you or others an
> idea how to verify or debug the problem? I still have here also a MSVC
> and a two year old MINGW runtime environment with that I can do some
> debugging. Building emacs on that environments still works fine.
>
> Harald
>
> Loading help...
> Loading international/mule-cmds...
> Loading case-table...
> Loading international/utf-8...
> Loading international/utf-16...
> Loading international/characters...
> End of file during parsing: g:/cvs/emacs-cygwin/lisp/international/characters.elc
> Signal 127
> make.exe[1]: *** [oo-spd/i386/emacs.exe] Error 255
> make.exe[1]: Leaving directory `g:/cvs/rc/emacs-cygwin/src'
> d:\usr\mingw-make\bin\make.exe: *** [all-other-dirs-gmake] Error 2

FYI. Just figured out that same problem exists in CVS emacs.

Harald

Re: [h-e-w] Current word on binaries (EMACS_21_1_RC on cygwin)

[Richard Stallman]

    I took the changes and all works fine if emacs is compiled with no
    optimizations (--no-opt). If I turn on optimizations then I get the
    following re-producable errors.

In such a case, it is necessary to track down where in Emacs the code
executes wrong, much as if you were looking for any other kind of Emacs
bug.

Once the problem is localized, you may find code that is not
well-defined C.  Or you may find a line that is miscompiled.  If it is
the latter, we would want to send a GCC bug report.

    I still have here also a MSVC
    and a two year old MINGW runtime environment with that I can do some
    debugging.

If the problem does not happen with them, then they are irrelevant to
it.  The way to find a bug is to debug the case that fails.
Investigating cases that don't fail won't tell you about the failure.