mirror of
git://git.sv.gnu.org/coreutils.git
synced 2026-02-20 14:22:26 +02:00
880a6e7723
* README-release: Remove mention of bootstrap's old --gnulib-srcdir=/gnulib option. No longer needed, and its use can lead to subtle problems.
98 lines
3.4 KiB
Plaintext
98 lines
3.4 KiB
Plaintext
Here are most of the steps we (maintainers) follow when making a release.
|
|
|
|
* start from a clean, up-to-date git directory.
|
|
|
|
git checkout master; git pull
|
|
|
|
* Run ./configure && make maintainer-clean
|
|
|
|
* Ensure that the desired versions of autoconf, automake, bison, etc.
|
|
are in your PATH. See HACKING for the complete list.
|
|
|
|
* Ensure that you're on "master" with no uncommitted diffs.
|
|
This should produce no output: git checkout master; git diff
|
|
|
|
* Make sure your local gnulib directory is up to date.
|
|
|
|
* Run bootstrap: ./bootstrap
|
|
|
|
FIXME: enable excluded programs like arch? to get their manual pages?
|
|
|
|
* Pre-release testing:
|
|
On at least one SELinux-enabled (enforcing) and one non-SELinux system,
|
|
run all tests, both root-only and regular.
|
|
Run *all* non-root tests, including expensive and very expensive ones i.e.,
|
|
run this: make -j1 check RUN_VERY_EXPENSIVE_TESTS=yes RUN_EXPENSIVE_TESTS=yes
|
|
|
|
Run the root-only tests:
|
|
sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root
|
|
|
|
* Run "make distcheck"
|
|
|
|
* Manually set the date, version number, and [stable/alpha/beta] on
|
|
line 3 of NEWS, then do e.g.,:
|
|
|
|
v=7.3
|
|
git commit -F <(printf 'version '$v'\n\n* NEWS: Record release date.\n') -a
|
|
git tag -s -m "coreutils $v" v$v HEAD
|
|
|
|
* Run the following to create release tarballs. Your choice selects the
|
|
corresponding upload-to destination in the emitted gnupload command.
|
|
The different destinations are specified in cfg.mk. See the definitions
|
|
of gnu_ftp_host-{alpha,beta,major}.
|
|
|
|
# "TYPE" must be major, beta or alpha
|
|
make TYPE
|
|
|
|
* Test the tarball. copy it to a few odd-ball systems and ensure that
|
|
it builds and passes all tests.
|
|
|
|
* While that's happening, write the release announcement that you will
|
|
soon post.
|
|
|
|
Once all the builds and tests have passed,
|
|
|
|
* Run the gnupload command that was suggested by your "make major" run above.
|
|
|
|
* Wait a few minutes (maybe up to 30?) and then use the release URLs to
|
|
download all tarball/signature pairs and use gpg --verify to ensure
|
|
that they're all valid.
|
|
|
|
* Push the new tag:
|
|
git push origin tag v<JUST_RELEASED_VERSION_NUMBER>
|
|
|
|
* Send the gpg-signed announcement mail, e.g.,
|
|
To: info-gnu@gnu.org, coreutils-announce@gnu.org
|
|
Cc: coordinator@translationproject.org, bug-coreutils@gnu.org
|
|
Subject: coreutils-7.1 released [stable]
|
|
|
|
* Approve the announcement here:
|
|
http://lists.gnu.org/mailman/admindb/coreutils-announce
|
|
|
|
* Announce it on Savannah, too:
|
|
From here:
|
|
https://savannah.gnu.org/projects/coreutils/
|
|
click on the "submit news", then write something like the following:
|
|
|
|
Subject: coreutils-7.2 released [stable]
|
|
The announcement is here:
|
|
http://article.gmane.org/gmane.comp.gnu.core-utils.announce/49
|
|
|
|
Then go here to approve it:
|
|
https://savannah.gnu.org/news/approve.php?group=coreutils
|
|
|
|
* For non-alpha releases, update the on-line manual at
|
|
|
|
http://www.gnu.org/software/coreutils/manual/
|
|
|
|
Run `make web-manual', then copy the contents of doc/manual
|
|
into a CVS checkout of the coreutils manual repository.
|
|
Also edit coreutils.html (FIXME? why?) before doing a CVS commit.
|
|
|
|
CVS_RSH=ssh \
|
|
cvs -d:ext:$USER@cvs.savannah.gnu.org:/web/coreutils co coreutils
|
|
|
|
Be sure to "cvs add -ko" any files that "cvs status" marks with "?".
|
|
That is necessary whenever a new texinfo node is added. Each becomes
|
|
a new file in html_node that must then be "cvs add"ed.
|