and don't have autoconf installed. They'll be unable to make without playing
around with `touch'.
-The correct order to commit the configure-related files is:
-
-% cvs commit acconfig.h aclocal.m4 config.h.in configure.in configure stamp-h.in
-
-If you haven't changed all of those files, just commit the rest in the
-stated order (e.g. cvs commit acconfig.h config.h.in stamp-h.in).
+The correct procedure to commit the configure-related files is:
+
+ % cvs commit acconfig.h aclocal.m4 configure.in
+ % autoconf && autoheader # or simply "make"
+ % cvs commit config.h.in configure
+ % make stamp-h.in # or simply "make"
+ % cvs commit stamp-h.in
+
+The reason that the commits need to be split up is that the RCS Id strings
+in the files change when you commit, which can apparently mess up the
+dependencies. [How? -- Dan Harkless <dan-nmh@dilvish.speed.net> // CVS
+updates the strings to have the new version number, the modification time
+of the file gets updated by the OS. -- Kimmo Suominen <kim@tac.nyc.ny.us>]
+If this were not the case, you could commit with a single make followed by a
+cvs commit acconfig.h aclocal.m4 config.h.in configure.in configure stamp-h.in.
+[But since we have the RCS Id strings in the files, isn't it useless to even
+mention this? The fix would be to remove the strings, and I don't think that
+would be good. -- Kimmo Suominen <kim@tac.nyc.ny.us>]
+
+If you haven't changed all the files noted above, just commit the ones you have,
+in the stated order (for instance, configure.in, then configure, then
+stamp-h.in).
-------------------
"time". Date and time manipulation routines go here.
+-------------------------------------------------------
+nmh-local functions to use in preference to OS versions
+-------------------------------------------------------
+
+For some system functions whose availability or behavior varies from OS to OS,
+nmh conditionally uses a local definition with the same name as the OS function
+(e.g. snprintf()). For other functions, developers need to avoid the OS
+versions and always use the nmh-supplied function. Here is a list of such
+functions:
+
+OS function nmh-local version to use instead
+=========== ================================
+getpass() nmh_getpass()
+
+
-------------
releasing nmh
-------------
To make a public release of nmh (we'll use version 1.0.4 and my mhost.com
account, danh, as examples here):
-1. % echo 1.0.4 > VERSION
+ 1. % echo 1.0.4 > VERSION
+
+ 2. Put a comment like "Released nmh-1.0.4." in the ChangeLog.
+
+ 3. % cvs commit ChangeLog VERSION
+
+ 4. % cvs tag nmh-1_0_4
+ (cvs treats dots specially, so underscores are substituted here.)
+
+ 5. % make nmhdist
+
+ 6. Untar nmh-1.0.4.tar.gz and `diff -r' it vs. your CVS tree. 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).
+
+ 7. If you have root access on your machine, it's good at this point to do:
+
+ % 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
+
+ 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.
-2. Put a comment like "Released nmh-1.0.4." in the ChangeLog.
+ 8. Make sure your new tarball uncompresses and untars with no problem. Make
+ sure you can configure, make, and install nmh from it.
-3. % cvs commit ChangeLog VERSION
+ 9. If all is well and your tarball is final, go back to your CVS tree and do:
-4. % cvs tag nmh-1_0_4
- (cvs treats dots specially, so underscores are substituted here.)
+ % echo 1.0.4+dev > VERSION
-5. % make nmhdist
+10. Put a comment like "Upped the version number to 1.0.4+dev until the next nmh
+ release." in the ChangeLog.
-6. Preferably make an MD5 hash and/or a PGP signature of nmh-1.0.4.tar.gz.
+11. % cvs commit ChangeLog VERSION
-7. Preferably test out the tarball, making sure you can uncompress and untar it,
- and configure, make, install, and use nmh from it.
+12. If possible, make an MD5 hash and/or a PGP signature of nmh-1.0.4.tar.gz.
-8. % scp -p nmh-1.0.4.tar.gz* danh@mhost.com:/home/ftp/pub/nmh
+13. % scp -p nmh-1.0.4.tar.gz* danh@mhost.com:/var/ftp/pub/nmh
-9. Send an announcement to exmh-users@redhat.com, exmh-workers@redhat.com,
- mh-users@ics.uci.edu, and nmh-announce@mhost.com. If the release fixes
- significant security holes, also send an announcement to
- bugtraq@securityfocus.com. The exmh lists require you to be subscribed in
- order to post. Note that you don't need to post separately to comp.mail.mh,
- as the mh-users mailing list is apparently bidirectionally gatewayed to it.
+14. Send an announcement to exmh-users@redhat.com, exmh-workers@redhat.com,
+ mh-users@ics.uci.edu, and nmh-announce@mhost.com. If the release fixes
+ significant security holes, also send an announcement to
+ bugtraq@securityfocus.com. The exmh lists require you to be subscribed in
+ order to post. Note that you don't need to post separately to comp.mail.mh,
+ as the mh-users mailing list is apparently bidirectionally gatewayed to it.
- Preferably, the announcement should contain the MD5 hash generated above, and
- should be PGP-signed. It should include the FTP URL for the tarball as well
- as the URL of the website. It should contain a brief summary of visible
- changes, as well as the URL of the cvsweb diff page that would show a
- detailed list of changes. The changes between 1.0.3 and 1.0.4 would be shown
- by:
+ Preferably, the announcement should contain the MD5 hash generated above,
+ and should be PGP-signed. It should include the FTP URL for the tarball as
+ well as the URL of the website. It should contain a brief summary of
+ visible changes, as well as the URL of the cvsweb diff page that would show
+ a detailed list of changes. The changes between 1.0.3 and 1.0.4 would be
+ shown by:
- http://www.mhost.com/cgi-bin/cvsweb/nmh/ChangeLog?r1=1.40&r2=1.71
+ http://www.mhost.com/cgi-bin/cvsweb/nmh/ChangeLog?r1=1.40&r2=1.71
projects / mmh / blobdiff