summaryrefslogtreecommitdiff
path: root/README.git
diff options
context:
space:
mode:
authorPaul Smith <psmith@gnu.org>2022-10-30 09:31:35 -0400
committerPaul Smith <psmith@gnu.org>2022-10-31 02:23:04 -0400
commit7c3260bbdd40c234534e77ffb95ccbe0a6dced7b (patch)
treecff98b4fa08998da44108bb346e1fd05226f8bd7 /README.git
parent38b19976f50af0c898030adcb86320bdfe52a159 (diff)
downloadmake-git-7c3260bbdd40c234534e77ffb95ccbe0a6dced7b.tar.gz
* README.git: Update and clarify release operations
Diffstat (limited to 'README.git')
-rw-r--r--README.git157
1 files changed, 92 insertions, 65 deletions
diff --git a/README.git b/README.git
index 579bcb57..55a545bf 100644
--- a/README.git
+++ b/README.git
@@ -48,8 +48,8 @@ your commit messages (sans the leading TAB of course).
Rule #1: Don't rewrite pushed history on master (no "git push --force").
Rule #2: Feel free to rewrite pushed history on personal branches.
-Rule #3: Prefer to squash-merge or rebase + merge --ff-only, rather than
- merging from personal branches into master.
+Rule #3: Squash-merge or rebase + merge --ff-only, rather than merging from
+ personal branches into master.
Typical simple workflow might be:
@@ -178,6 +178,9 @@ Note, neither of these methods are tested regularly by the GNU Make
maintainers. Building for Windows from a distribution tarball IS tested
regularly.
+NOTE! "Maintainer mode" (see above) IS ENABLED when building from Git using
+ the build_w32.bat file.
+
Debugging and Testing
---------------------
@@ -203,7 +206,7 @@ work on non-GNU systems (Windows, MacOS, etc.)
make clean
make -j8 CFLAGS='-ggdb3 -fsanitize=address' LDFLAGS='-ggdb3 -fsanitize=address'
- (cd tests && ./run_make_tests -make ../make)
+ make check
Note that ASAN is reporting many more errors than valgrind. I don't know
which one is wrong: I haven't looked at them closely.
@@ -250,99 +253,123 @@ consistent (that's why we don't finalize the Git tag, etc. until the end).
"Fixed Release" ID number.
* Run "make distcheck" to be sure it all works.
* Run "make check-alt-config" to be sure alternative configurations work
- * Run "make update-makeweb" to get a copy of the GNU Make web pages
- * Run "make update-gnuweb" to get a copy of the GNU website boilerplate pages
- * Update the web page boilerplate if necessary:
- ../gnu-www/www/server/standards/patch-from-parent ../make-web/make.html \
- ../gnu-www/www/server/standards/boilerplate.html
- * Run "make gendocs" (requires gnulib) to generate the manual files for
- the GNU Make web pages.
- * Follow the directions from gendocs for the web page repository
* run "make tag-release" to create a Git tag for the release
* Push everything:
git push --tags origin master
-Manage the Savannah project for GNU Make:
+The safest thing is to create an entirely new repository and build the final
+package from there:
- >>> This is only for real releases, not release candidate builds <<<
+ git clone git://git.savannah.gnu.org/make.git make-release
+ cd make-release
- * In Savannah modify the "Value", "Rank", and "Description" values for the
- current "SCM" entry in both "Component Version" and "Fix Release" fields
- to refer to the new release. The "Rank" field should be 10 less than the
- previous release so it orders properly.
- * In Savannah create a new entry for the "Component Version" and "Fix
- Release" fields:
- - Value: SCM
- - Rank: 20
- - Descr: Issues found in code retrieved from Source Code Management (Git), rather than a distributed version. Please include the SHA you are working with.
+If you don't want to create a new repository then run "git clean -fdx".
+Then:
- - Descr: Fixed in Source Code Management (Git). The fix will be included in the next release of GNU Make.
+ ./bootstrap.sh
+ ./configure
+ make distcheck
-Start the next release:
+Perform test builds on whichever systems you have access to.
- * Update configure.ac and add a ".90" to the release number.
- * Update the NEWS file with a new section for the release / date.
- * Update the Savannah URL for the bugs fixed in the NEWS section.
+Use a previous announcement as a template to create an announcement in a text
+file then sign it with GPG:
+ gpg --clearsign <announcement.txt>
-Publishing a Package
---------------------
+Or, use your mail client's PGP/GPG signing capabilities.
-In order to publish a package on the FSF FTP site, either the release
-site ftp://ftp.gnu.org, or the prerelease site ftp://alpha.gnu.org, you
-first need to have my GPG private key and my passphrase to unlock it.
-And, you can't have them! So there! But, just so I remember here's
-what to do:
+NOTE! In order to publish a package on the FSF FTP site you need to have my
+ GPG private key, and my passphrase to unlock it.
- Make sure the "Steps to Release" are complete and committed and tagged.
+ Depending on your distribution (whether GnuPG is integrated with your
+ keyring etc.) the upload operation will either pop up a window asking
+ for the GPG key passphrase one time, or else it will use the CLI to ask
+ for the GPG passphrase _THREE_ times. Sigh.
- git clone git://git.savannah.gnu.org/make.git make-release
- cd make-release
+Publishing a Release Candidate
+------------------------------
- <run the commands above to build the release>
+Usually I publish one or two release candidates for people to test before
+making an official release. Release candidates use a GNU numbering scheme,
+which add a ".9x" release number to the PREVIOUS major release. So the first
+release candidate for GNU Make 4.4 would be GNU Make 4.3.90, the second
+release candidate would be 4.3.91, etc.
- make upload-alpha # for alpha.gnu.org (pre-releases)
- -OR-
- make upload-ftp # for ftp.gnu.org (official releases)
+Upload a release candidate using:
-Depending on your distribution (whether GnuPG is integrated with your keyring
-etc.) it will either pop up a window asking for your GPG key passphrase one
-time, or else it will use the CLI to ask for the GPG passphrase _THREE_ times.
-Sigh.
+ make upload-alpha
+Announce a release candidate to these mailing lists:
-For both final releases and pre-releases, send an email with the URL of
-the package to the GNU translation robot to allow the translators to
-work on it:
+ To: bug-make@gnu.org
+ BCC: help-make@gnu.org, make-w32@gnu.org, make-alpha@gnu.org
- <coordinator@translationproject.org>
+You will have to approve the BCC's on the mailing list admin sites. Send
+separate copies to (don't use CC as replies will go to these lists):
+ * coordinator@translationproject.org
+ * platform-testers@gnu.org
-Where to Announce
------------------
-Create the announcement in a text file, using 'git shortlog',
-then sign it with GPG:
+Publishing a Release
+--------------------
- gpg --clearsign <announcement.txt>
+When publishing a final release there are extra steps that need to be taken:
-Or, use your mail client's PGP/GPG signing capabilities.
+ * Run "make update-makeweb" to get a copy of the GNU Make web pages
+ * Run "make update-gnuweb" to get a copy of the GNU website boilerplate pages
+ * Update the web page boilerplate if necessary:
+ ( cd ~/src/make/make-web \
+ && ~/src/gnu-www/www/server/standards/patch-from-parent \
+ make.html \
+ ~/src/gnu-www/www/server/standards/boilerplate.html )
+ * Run "make gendocs" (requires gnulib) to generate the manual files for
+ the GNU Make web pages.
+ * Follow the directions from gendocs for the web page repository
-Announce the release:
+Manage the Savannah project for GNU Make:
- * For release candidate builds:
- To: bug-make@gnu.org
- CC: coordinator@translationproject.org, platform-testers@gnu.org
- BCC: help-make@gnu.org, make-w32@gnu.org, make-alpha@gnu.org
+ * In Savannah modify the "Value", "Rank", and "Description" values for the
+ current "SCM" entry in both "Component Version" and "Fix Release" fields
+ to refer to the new release. The "Rank" field should be 10 less than the
+ previous release so it orders properly.
+
+ * In Savannah create a new entry for the "Component Version" field:
+ - Value: SCM
+ - Rank: 20
+ - Descr: Issues found in code retrieved from Source Code Management (Git), rather than a distributed version. Please include the SHA you are working with.
+
+ * In Savannah create a new entry for the "Fix Release" field:
+ - Value: SCM
+ - Rank: 20
+ - Descr: Fixed in Source Code Management (Git). The fix will be included in the next release of GNU Make.
+
+Upload a release using:
+
+ make upload-ftp
+
+Announce a release to these mailing lists:
- * For release builds
To: info-gnu@gnu.org, bug-make@gnu.org
- CC: coordinator@translationproject.org
BCC: help-make@gnu.org, make-w32@gnu.org, make-alpha@gnu.org
- * Add a news item to the Savannah project site.
- * Add an update to freecode.com (nee freshmeat.net)
+You will have to approve the BCC's on the mailing list admin sites. Send
+separate copies to (don't use CC as replies will go to these lists):
+
+ * coordinator@translationproject.org
+ * platform-testers@gnu.org
+
+Announce on Savannah:
+
+ * Add a news item to the Savannah project site.
+
+Start the next release:
+
+ * Update configure.ac and add a ".90" to the release number.
+ * Update the NEWS file with a new section for the release / date.
+ * Update the Savannah URL for the bugs fixed in the NEWS section.
Appendix A - For The Brave
@@ -360,6 +387,6 @@ For a debugging version:
./bootstrap && ./configure CFLAGS=-g && make check
-For a release version
+For an optimized version
./bootstrap && ./configure && make check