mirror of
https://git.savannah.gnu.org/git/make.git
synced 2025-02-12 08:38:47 +00:00
* README.git: Update and clarify release operations
This commit is contained in:
parent
38b19976f5
commit
7c3260bbdd
1 changed files with 103 additions and 76 deletions
179
README.git
179
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 #1: Don't rewrite pushed history on master (no "git push --force").
|
||||||
Rule #2: Feel free to rewrite pushed history on personal branches.
|
Rule #2: Feel free to rewrite pushed history on personal branches.
|
||||||
Rule #3: Prefer to squash-merge or rebase + merge --ff-only, rather than
|
Rule #3: Squash-merge or rebase + merge --ff-only, rather than merging from
|
||||||
merging from personal branches into master.
|
personal branches into master.
|
||||||
|
|
||||||
Typical simple workflow might be:
|
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
|
maintainers. Building for Windows from a distribution tarball IS tested
|
||||||
regularly.
|
regularly.
|
||||||
|
|
||||||
|
NOTE! "Maintainer mode" (see above) IS ENABLED when building from Git using
|
||||||
|
the build_w32.bat file.
|
||||||
|
|
||||||
|
|
||||||
Debugging and Testing
|
Debugging and Testing
|
||||||
---------------------
|
---------------------
|
||||||
|
@ -203,7 +206,7 @@ work on non-GNU systems (Windows, MacOS, etc.)
|
||||||
|
|
||||||
make clean
|
make clean
|
||||||
make -j8 CFLAGS='-ggdb3 -fsanitize=address' LDFLAGS='-ggdb3 -fsanitize=address'
|
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
|
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.
|
which one is wrong: I haven't looked at them closely.
|
||||||
|
@ -250,34 +253,118 @@ consistent (that's why we don't finalize the Git tag, etc. until the end).
|
||||||
"Fixed Release" ID number.
|
"Fixed Release" ID number.
|
||||||
* Run "make distcheck" to be sure it all works.
|
* Run "make distcheck" to be sure it all works.
|
||||||
* Run "make check-alt-config" to be sure alternative configurations work
|
* 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
|
* run "make tag-release" to create a Git tag for the release
|
||||||
* Push everything:
|
* Push everything:
|
||||||
git push --tags origin master
|
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
|
||||||
|
|
||||||
|
If you don't want to create a new repository then run "git clean -fdx".
|
||||||
|
Then:
|
||||||
|
|
||||||
|
./bootstrap.sh
|
||||||
|
./configure
|
||||||
|
make distcheck
|
||||||
|
|
||||||
|
Perform test builds on whichever systems you have access to.
|
||||||
|
|
||||||
|
Use a previous announcement as a template to create an announcement in a text
|
||||||
|
file then sign it with GPG:
|
||||||
|
|
||||||
|
gpg --clearsign <announcement.txt>
|
||||||
|
|
||||||
|
Or, use your mail client's PGP/GPG signing capabilities.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
Publishing a Release Candidate
|
||||||
|
------------------------------
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Upload a release candidate using:
|
||||||
|
|
||||||
|
make upload-alpha
|
||||||
|
|
||||||
|
Announce a release candidate to these mailing lists:
|
||||||
|
|
||||||
|
To: bug-make@gnu.org
|
||||||
|
BCC: help-make@gnu.org, make-w32@gnu.org, make-alpha@gnu.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
|
||||||
|
|
||||||
|
|
||||||
|
Publishing a Release
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
When publishing a final release there are extra steps that need to be taken:
|
||||||
|
|
||||||
|
* 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
|
||||||
|
|
||||||
|
Manage the Savannah project for GNU Make:
|
||||||
|
|
||||||
* In Savannah modify the "Value", "Rank", and "Description" values for the
|
* In Savannah modify the "Value", "Rank", and "Description" values for the
|
||||||
current "SCM" entry in both "Component Version" and "Fix Release" fields
|
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
|
to refer to the new release. The "Rank" field should be 10 less than the
|
||||||
previous release so it orders properly.
|
previous release so it orders properly.
|
||||||
* In Savannah create a new entry for the "Component Version" and "Fix
|
|
||||||
Release" fields:
|
* In Savannah create a new entry for the "Component Version" field:
|
||||||
- Value: SCM
|
- Value: SCM
|
||||||
- Rank: 20
|
- 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.
|
- 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.
|
- 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:
|
||||||
|
|
||||||
|
To: info-gnu@gnu.org, bug-make@gnu.org
|
||||||
|
BCC: help-make@gnu.org, make-w32@gnu.org, make-alpha@gnu.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
|
||||||
|
|
||||||
|
Announce on Savannah:
|
||||||
|
|
||||||
|
* Add a news item to the Savannah project site.
|
||||||
|
|
||||||
Start the next release:
|
Start the next release:
|
||||||
|
|
||||||
* Update configure.ac and add a ".90" to the release number.
|
* Update configure.ac and add a ".90" to the release number.
|
||||||
|
@ -285,66 +372,6 @@ Start the next release:
|
||||||
* Update the Savannah URL for the bugs fixed in the NEWS section.
|
* Update the Savannah URL for the bugs fixed in the NEWS section.
|
||||||
|
|
||||||
|
|
||||||
Publishing a Package
|
|
||||||
--------------------
|
|
||||||
|
|
||||||
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:
|
|
||||||
|
|
||||||
Make sure the "Steps to Release" are complete and committed and tagged.
|
|
||||||
|
|
||||||
git clone git://git.savannah.gnu.org/make.git make-release
|
|
||||||
|
|
||||||
cd make-release
|
|
||||||
|
|
||||||
<run the commands above to build the release>
|
|
||||||
|
|
||||||
make upload-alpha # for alpha.gnu.org (pre-releases)
|
|
||||||
-OR-
|
|
||||||
make upload-ftp # for ftp.gnu.org (official releases)
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
||||||
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:
|
|
||||||
|
|
||||||
<coordinator@translationproject.org>
|
|
||||||
|
|
||||||
|
|
||||||
Where to Announce
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
Create the announcement in a text file, using 'git shortlog',
|
|
||||||
then sign it with GPG:
|
|
||||||
|
|
||||||
gpg --clearsign <announcement.txt>
|
|
||||||
|
|
||||||
Or, use your mail client's PGP/GPG signing capabilities.
|
|
||||||
|
|
||||||
Announce the release:
|
|
||||||
|
|
||||||
* 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
|
|
||||||
|
|
||||||
* 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)
|
|
||||||
|
|
||||||
|
|
||||||
Appendix A - For The Brave
|
Appendix A - For The Brave
|
||||||
--------------------------
|
--------------------------
|
||||||
|
|
||||||
|
@ -360,6 +387,6 @@ For a debugging version:
|
||||||
|
|
||||||
./bootstrap && ./configure CFLAGS=-g && make check
|
./bootstrap && ./configure CFLAGS=-g && make check
|
||||||
|
|
||||||
For a release version
|
For an optimized version
|
||||||
|
|
||||||
./bootstrap && ./configure && make check
|
./bootstrap && ./configure && make check
|
||||||
|
|
Loading…
Reference in a new issue