From 0287c2e441fbc748cb11f96a5afd6dbdf68b0818 Mon Sep 17 00:00:00 2001 From: Ken Hornstein Date: Mon, 6 Feb 2012 10:27:43 -0500 Subject: [PATCH] Update the developer documentation with the changes to the release process. --- docs/README.developers | 59 +++++++++++++++++------------------------------- 1 file changed, 21 insertions(+), 38 deletions(-) diff --git a/docs/README.developers b/docs/README.developers index cba9f46..3876ba6 100644 --- a/docs/README.developers +++ b/docs/README.developers @@ -136,67 +136,50 @@ getpass() nmh_getpass() releasing nmh ------------- -To make a public release of nmh (we'll use version 1.0.4 and my mhost.com +To make a public release of nmh (we'll use version 1.5 and my mhost.com account, danh, as examples here; the convention for release candidates -is to use something like "1.0.4-RC1"): +is to use something like "1.5-RC1"): - 1. % echo 1.0.4 > VERSION + 1. % echo 1.5 > VERSION % date +"%e %B %Y" > DATE (DATE should contain something like "30 December 2000") 2. % git commit VERSION DATE; git push - 3. % git tag -a nmh-1_0_4 -m 'Releasing nmh-1_0_4.' + 3. % git tag -a 1.5 -m 'Releasing nmh-1.5.' - 4. % make nmhdist + Note that the new convention for tagging is to simply tag with the + version number (tag formats in the past have varied). - 5. Untar nmh-1.0.4.tar.gz and `diff -r' it vs. your workspace. Make - sure no files got left out of the distribution that should be in - it (due to someone forgetting to update the DIST variables in the - Makefiles). + 4. % make distcheck - 6. If you have root access on your machine, it's good at this point to do: + If you want to check the distribution build with some particular + configure options, set the DISTCHECK_CONFIGURE_FLAGS variable. + E.g.: - % chown -R 0:0 nmh-1.0.4 - % tar cvf nmh-1.0.4.tar nmh-1.0.4 - % gzip nmh-1.0.4.tar + % make distcheck DISTCHECK_CONFIGURE_FLAGS=--with-cyrus-sasl - If you leave the files in the archive as being owned by yourself, your UID - may coincide with one of a user on a machine where nmh is being installed, - making it possible for that user to Trojan the nmh code before the system - administrator finishes installing it. - - 7. Make sure your new tarball uncompresses and untars with no problem. Make - sure you can configure, make, and install nmh from it. - - 8. If all is well and your tarball is final, go back to your workspace and do: + 5. If all is well and your tarball is final, go back to your workspace and do: % echo 1.0.4+dev > VERSION - 9. % git commit VERSION; git push - -10. If possible, make an MD5 hash and/or a PGP signature of nmh-1.0.4.tar.gz. - Assuming you have gpg set up, this should be: - % gpg --output nmh-1.0.4.tar.gz.sig --detach-sig nmh-1.0.4.tar.gz + 6. % git commit VERSION; git push - You can verify the signature with - % gpg --verify nmh-1.0.4.tar.gz.sig nmh-1.0.4.tar.gz + 7. Upload the distribution file to savannah. You can automate this process + by doing: -11. Upload the files to savannah. First make sure they are mode 664 so - they will have the right permissions on the server end - (see https://savannah.gnu.org/maintenance/SharedDownloadArea) - % chmod 664 nmh-1.0.4.tar.gz* + % make upload SAVANNAH_USERNAME=username - Then scp them across: - % scp -p nmh-1.0.4.tar.gz* youruser@dl.sv.nongnu.org:/releases/nmh/ + This will automatically call gpg to sign the release. You can bypass + this step by setting the SKIP_GPG_SIG variable. -12. Update the http://www.nongnu.org/nmh/ homepage. (It lives in the CVS + 8. Update the http://www.nongnu.org/nmh/ homepage. (It lives in the CVS 'webpages repository'; see https://savannah.nongnu.org/cvs/?group=nmh) -13. Add a news item to the savannah nmh page. You'll have to submit it first + 9. Add a news item to the savannah nmh page. You'll have to submit it first and then separately approve it (under News->Manage). -14. Send the release announcement email to the following places: +10. Send the release announcement email to the following places: nmh-workers@nongnu.org nmh-announce@nongnu.org exmh-users@redhat.com -- 1.7.10.4