Internals Create-a-Release

This page was produced by an automated import process, and may have formatting errors; feel free to fix.

Create a Release

The process of creating and then making available a release is broken down into a number of stages. The first part addresses the technical process of creating a releasable tar ball. The later stages address the process of releasing that tar ball.

When making a release candidate just the first section is needed. [Create-a-release-candidate ]

Create a release candidate

The objective at this stage is to create a set of tar balls that can be made available as a formal release (or as a less formal release candidate). [Freeze-the-branch ]

Freeze the branch

Send out an e-mail notifying everyone that the branch is frozen to [mailto:gdb-patches@sourceware.org gdb-patches@sourceware.org]. [Establish-a-few-defaults_002e ]

Establish a few defaults.

$  b=gdb_5_2-branch
$  v=5.2
$  t=/sourceware/snapshot-tmp/gdbadmin-tmp
$  echo $t/$b/$v
/sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_2-branch/5.2
$  mkdir -p $t/$b/$v
$  cd $t/$b/$v
$  pwd
/sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_2-branch/5.2
$  which autoconf
/home/gdbadmin/bin/autoconf
$

Notes:

Check the autoconf version carefully. You want to be using the version documented in the toplevel README-maintainer-mode file. It is very unlikely that the version of autoconf installed in system directories (e.g., /usr/bin/autoconf) is correct. [Check-out-the-relevant-modules_003a ]

Check out the relevant modules:

$  for m in gdb insight
do
( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m )
done
$

Note:

The reading of .cvsrc is disabled (-f) so that there isn’t any confusion between what is written here and what your local cvs really does. [Update-relevant-files_002e ]

Update relevant files.

gdb/NEWS

Major releases get their comments added as part of the mainline. Minor releases should probably mention any significant bugs that were fixed.

Don’t forget to include the ChangeLog entry.

$  emacs gdb/src/gdb/NEWS
...
c-x 4 a
...
c-x c-s c-x c-c
$  cp gdb/src/gdb/NEWS insight/src/gdb/NEWS 
$  cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog

gdb/README

You’ll need to update:

The version.
The update date.
Who did it.

$  emacs gdb/src/gdb/README
...
c-x 4 a
...
c-x c-s c-x c-c
$  cp gdb/src/gdb/README insight/src/gdb/README 
$  cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog

Maintainer note: Hopefully the README file was reviewed before the initial branch was cut so just a simple substitute is needed to get it updated.

Maintainer note: Other projects generate README and INSTALL from the core documentation. This might be worth pursuing.

gdb/version.in

$  echo $v > gdb/src/gdb/version.in
$  cat gdb/src/gdb/version.in
5.2
$  emacs gdb/src/gdb/version.in
...
c-x 4 a
... Bump to version ...
c-x c-s c-x c-c
$  cp gdb/src/gdb/version.in insight/src/gdb/version.in 
$  cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog

[Do-the-dirty-work ]

Do the dirty work

This is identical to the process used to create the daily snapshot.

$  for m in gdb insight
do
( cd $m/src && gmake -f src-release $m.tar )
done

If the top level source directory does not have src-release (GDB version 5.3.1 or earlier), try these commands instead:

$  for m in gdb insight
do
( cd $m/src && gmake -f Makefile.in $m.tar )
done

[Check-the-source-files ]

Check the source files

You’re looking for files that have mysteriously disappeared. distclean has the habit of deleting files it shouldn’t.

$  ( cd gdb/src && cvs -f -q -n update )
M djunpack.bat
? gdb-5.1.91.tar
? proto-toplev
&#8230; lots of generated files &#8230;
M gdb/ChangeLog
M gdb/NEWS
M gdb/README
&#8230; lots of generated files &#8230;
$

Don’t worry about the gdb.info-?? or gdb/p-exp.tab.c. They were generated (and yes gdb.info-1 was also generated only something strange with CVS means that they didn’t get suppressed). Fixing it would be nice though. [Create-compressed-versions-of-the-release ]

Create compressed versions of the release

$  cp */src/*.tar .
$  cp */src/*.bz2 .
$  ls -F
gdb/ gdb-5.2.tar insight/ insight-5.2.tar
$  for m in gdb insight
do
bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2
gzip -v -9 -c $m-$v.tar > $m-$v.tar.gz
done
$

Note:

A pipe such as bunzip2 < xxx.bz2 | gzip -9 > xxx.gz is not since, in that mode, gzip does not know the name of the file and, hence, can not include it in the compressed file. This is also why the release process runs tar and bzip2 as separate passes. [Sanity-check-the-tar-ball ]

Sanity check the tar ball

Pick a popular machine (Solaris/PPC?) and try the build on that.

$  bunzip2 < gdb-5.2.tar.bz2 | tar xpf -
$  cd gdb-5.2
$  ./configure 
$  make
&#8230;
$  ./gdb/gdb ./gdb/gdb
GNU gdb 5.2
&#8230;
(gdb)  b main
Breakpoint 1 at 0x80732bc: file main.c, line 734.
(gdb)  run
Starting program: /tmp/gdb-5.2/gdb/gdb 

Breakpoint 1, main (argc=1, argv=0xbffff8b4) at main.c:734
734       catch_errors (captured_main, &args, "", RETURN_MASK_ALL);
(gdb)  print args
$1 = {argc = 136426532, argv = 0x821b7f0}
(gdb)

[Make-a-release-candidate-available ]

Make a release candidate available

If this is a release candidate then the only remaining steps are:

Commit version.in and ChangeLog
Tweak version.in (and ChangeLog to read L.M.N-DATE-cvs so that the version substitution process can restart.
Make the release candidate available in [ftp://sourceware.org/pub/gdb/snapshots/branch ftp://sourceware.org/pub/gdb/snapshots/branch]
Notify the relevant mailing lists ( [mailto:gdb@sourceware.org gdb@sourceware.org] and [mailto:gdb-testers@sourceware.org gdb-testers@sourceware.org] that the candidate is available. [Make-a-formal-release-available ]

Make a formal release available

(And you thought all that was required was to post an e-mail.) [Install-on-sware ]

Install on sware

Copy the new files to both the release and the old release directory:

$  cp *.bz2 *.gz ~ftp/pub/gdb/old-releases/
$  cp *.bz2 *.gz ~ftp/pub/gdb/releases

Clean up the releases directory so that only the most recent releases are available (e.g. keep 5.2 and 5.2.1 but remove 5.1):

$  cd ~ftp/pub/gdb/releases
$  rm &#8230;

Update the file README and .message in the releases directory:

$  vi README
&#8230;
$  rm -f .message
$  ln README .message

[Update-the-web-pages_002e ]

Update the web pages.

htdocs/download/ANNOUNCEMENT

This file, which is posted as the official announcement, includes:

General announcement.
News. If making an M.N.1 release, retain the news from earlier M.N release.
Errata.

htdocs/index.html htdocs/news/index.html htdocs/download/index.html

These files include:

Announcement of the most recent release.
News entry (remember to update both the top level and the news directory).

These pages also need to be regenerate using index.sh.

download/onlinedocs/

You need to find the magic command that is used to generate the online docs from the .tar.bz2. The best way is to look in the output from one of the nightly cron jobs and then just edit accordingly. Something like:

$  ~/ss/update-web-docs \
 ~ftp/pub/gdb/releases/gdb-5.2.tar.bz2 \
 $PWD/www \
 /www/sourceware/htdocs/gdb/download/onlinedocs \
 gdb

download/ari/

Just like the online documentation. Something like:

$  /bin/sh ~/ss/update-web-ari \
 ~ftp/pub/gdb/releases/gdb-5.2.tar.bz2 \
 $PWD/www \
 /www/sourceware/htdocs/gdb/download/ari \
 gdb

[Shadow-the-pages-onto-gnu ]

Shadow the pages onto gnu

Something goes here. [Install-the-GDB-tar-ball-on-GNU ]

Install the GDB tar ball on GNU

At the time of writing, the GNU machine was gnudist.gnu.org in ~ftp/gnu/gdb. [Make-the-ANNOUNCEMENT ]

Make the {{{ANNOUNCEMENT}}}

Post the ANNOUNCEMENT file you created above to:

[mailto:gdb-announce@sourceware.org GDB Announcement mailing list]
[mailto:info-gnu@gnu.org General GNU Announcement list] (but delay it a day or so to let things get out)
[mailto:bug-gdb@gnu.org GDB Bug Report mailing list] [Cleanup ]

Cleanup

The release is out but you’re still not finished. [Commit-outstanding-changes ]

Commit outstanding changes

In particular you’ll need to commit any changes to:

gdb/ChangeLog
gdb/version.in
gdb/NEWS
gdb/README [Tag-the-release ]

Tag the release

Something like:

$  d=`date -u +%Y-%m-%d`
$  echo $d
2002-01-24
$  ( cd insight/src/gdb && cvs -f -q update )
$  ( cd insight/src && cvs -f -q tag gdb_5_2-$d-release )

Insight is used since that contains more of the release than GDB. [Mention-the-release-on-the-trunk ]

Mention the release on the trunk

Just put something in the ChangeLog so that the trunk also indicates when the release was made. [Restart-gdb_002fversion_002ein ]

Restart {{{gdb/version.in}}}

If gdb/version.in does not have the string ‘DATE’ then builds will not include the checkout date in their resulting version. Having committed all the release changes it can be set to 5.2.0_DATE-cvs which will restart things.

Don’t forget the ChangeLog. [Merge-into-trunk ]

Merge into trunk

The files committed to the branch may also need changes merged into the trunk. [Revise-the-release-schedule ]

Revise the release schedule

Post a revised release schedule to [mailto:gdb@sourceware.org GDB Discussion List] with an updated announcement. The schedule can be generated by running:

$  ~/ss/schedule `date +%s` schedule

The first parameter is approximate date/time in seconds (from the epoch) of the most recent release.

Also update the schedule cronjob. [Post-release ]

Post release

Remove any OBSOLETE code.