Here is a maybe complete list of what I do to make releases.  Much of
it's history dates back to the very beginnings of the projects.  As an
example, the release tag format (Ext-VERSION-NUMBERS-HERE) dates back
to the fact that the very first releases I did were modifications to
the CMU code to make the agent "extensible", and hence the beginning
tag name.
   -- Wes 2002-08

***************************************************************************
**** IMPORTANT NOTES:
  - Don't *ever* release a second tar ball under the same name as the
    first.  It's much much much better to release another version
    instead, since you don't have to figure out from the bug reports
    that a user really grabbed the first snapshot instead of the
    second when they complain about version "XXX" not working.
  - It's entirely possible I haven't converted all the
    auto-done stuff into stuff which is auto-doable by other people.  I
    think I have, but check the results of everything!
  - Almost all version numbers in the various places are automatically
    incremented.  The ones that are not are noted below.
  - Much of the automation is done using the agent/mibroup/versiontag
    script which was originally written to support 3 different methods
    of making releases, but only one is used now.  It pulls the
    "Ext-VERSION-NUMBERS-HERE" tag apart and runs things based on the
    information.  It probably needs to be rewritten.  Probably in perl.
  - if you don't have cvs2cl installed, you can try and find a RPM for
    your architecture, or you can get it directly from the author (you
    may need to rename it from cvs2cl.pl to cvs2cl). The URL is:
       http://www.red-bean.com/cvs2cl/
    
    


***************************************************************************
TESTING:

  0) Update your source tree to catch everyones commits.  (I've forgotten this
     step before.)

     $ cvs update

  0b) run configure with as many modules as can be compiled on your
      machine to make sure there are no compile errors in any of the
      modules.  I frequently find some in the lesser developer-used
      modules, like Rmon, etc.  Something like:

      $ ./configure  '--with-mib-modules=host examples examples/example    \
                              testhandler smux Rmon disman/event-mib'    \
                   '--with-transports=UDPIPv6 TCPIPv6 IPX'               \
                   --enable-embedded-perl --enable-shared

      Alternatively, try using the new scripts in the dist directory, which
      *try* to do the correct thing for various releases and architectures.
      Assuming you are going to build in the source directory :

      $ cd SOURCE-DIR
      $ nsb-config -x -s $PWD

  1) [This step is currently only for the 5.x versions]

     a) Update libtool version

        Change the libtool version information in Makefile.top.  This may
        could be automated in the future, but libtool doesn't like you to
        match your project version with the library version so they have
        cases where the version numbers can't match.  I've looked into
        hacking libtool, and decided against it.  Follow the notes beyond
        the 3 variables:

          LIBCURRENT  = 5
          LIBREVISION = 3
          LIBAGE      = 0
     
        Functionally, it should match the release number
        LIBCURRENT.LIBAGE.LIBREVISION.  Do this now, so that when you run
        make in a second to test things you can spot libtool yelling
        about improper numbering before you make the release and not
        after you've uploaded the tar ball :-/

     b) Update the version number

        $ agent/mibgroup/versiontag Ext-5-0-3 reverse nocvs

     c) Edit version number in doxygen.conf file.

  2) Log into as many machines types as you can and run "make test".
     You should get perfect results.  If you don't, try running just
     those tests again with a slower sleep time (use the -S flag to
     testing/RUNTESTS).

  3) Make sure installing works.

     $ make install

  4) ideally, run make in the tutorial directories to make sure they
     compile properly after running "make install".

***************************************************************************
RELEASING:

  0) Update your source tree to catch everyones commits.  (I've forgotten this
     step before.)

     $ cvs update

  1) [This step is currently only for the 5.x versions]

     a) Check the sources for C++ style comments. 

        $ make commentcheck

        This will basically run a "grep" on all the sources for //.  It
        ignores things with "http:" in it as well as "/win32/".  Make
        sure there are no // comments in the main code body.

     b) Make the doxygen extracted manual pages.

        $ make docs

        (This copy the doxygen extracted manual pages to the man
        directory.  You'll have to then check these and commit them)
        Don't forget to update Makefile.in for any new manual pages.

        $ make mancp

  2) Create the appropriate NEWS file segments.  I usually do
     this by making a preliminary ChangeLog addition file (see step 5
     below for how to generate the ChangeLog).

  3) update the README file, if needed.

  4) Update Makefile dependencies:

        a) First, run configure using an appropriate module set.
           Don't do what I do all the time and accidentally include
           modules that don't exist in the source tree.  I suggest:

           $ ./configure  '--with-transports=UDPIPv6 TCPIPv6 IPX'          \
                        '--with-mib-modules=host examples examples/example \
                                    testhandler smux Rmon disman/event-mib' 


	b) Create the dependencies

           For 4.x:

             $ make makefileindepend

           For 5.x:

             $ make distdepend

           This runs a complicated series of scripts to update all the
           various Makefile.depend files sprinkled in the directories.
           These files are generated from the makedepend program, but
           are then stripped of non-local header files (ie, it removes
           all /usr/include/, ... references).  This makes the
           dependencies package-local.  This is sort of ugly, but
           still better than forcing the user to run "make depend"
           themselves (which they can still do if they want a more
           complete dependency list).  (and you can't assume they have
           makedepend around).

        c4) [This step is currently only for the 4.x versions]

           The dependencies are appended to 'Makefile.in', rather than a
           separate 'Makefile.depend'

        c5) [This step is currently only for the 5.x versions]

           Check in the dependencies

           $ cvs commit -m "make depend" `find . -name Makefile.depend`

           Note: The Makefile.depend is loaded by configure into the real
           Makefile when configure is run.

  5) Make sure all changes are checked in:

       $ cvs update
       $ cvs update

     (yes, twice) search for lines beginning with 'M' to make sure you
     don't have outstanding important changes.

  6) Update the ChangeLog file

       a) Extract the changelog

          [if you did this before above, do it again if you made any
           changes to the CVS tree since creating the last revision]

          $ cvs2cl -r -b -f ChangeLog.add --no-wrap -S

          Note that if you're on a branch, add the -F option to cvs2cl
          like:

          $ cvs2cl -r -f ChangeLog.add -F V4-2-patches --no-wrap -S

       b) Fixup the changelog

          $ perl dist/changelogfix < ChangeLog.add > ChangeLog.reallyadd

       c) Edit the ChangeLog file and insert the appropriate portion of the
          ChangeLog.reallyadd file.  You can usually find the point where
          the last release starts in the file by searching for "version tag".

          Please keep the line of dashes at the top of the file, as it
          makes it easier to copy during the next release.

          If using emacs, I suggest switching from changelog-mode to
          text-mode.

       d) Check in the new changelog

          $ cvs commit -m "update for release X" ChangeLog

  7) make the tarball:

        $ make dist VERSION=Ext-5-0-3 CVSUSER=hardaker

     This will make 5.0.3.  Basically, take the version number you
     want to produce and change the '.'s to '-'s.  Ext-8-1-3-pre1 will
     produce a net-snmp-8.1.3.pre1.tar.gz file in the current
     directory.

     This step does the following, much of it is a result of 2
     scripts: (agent/mibgroup/versiontag [location is purely
     historical], and remove-files):

        a) changes version numbers in important files.  Hopefully it
           didn't miss anything.
           propriate order
        b) Runs cvs tag
        c) Runs cvs export
        d) Removes some non-distributed files.  It also touches the
           configure files in the correct order so autoconf isn't
           auto-run by people who have extracted the tar file.
        e) Runs tar xzf ...

     At this point the sources are tagged.  If you need to make any
     changes, do so *before* you publish the tar ball to the web site.
     You'll likely need to move the tag using "cvs -F tag Ext-VERSION file.c".
     Then, you'll have to re-extract the code and tar it up.  You can
     do this by just running "make tar VERSION=Ext-5-0-3 CVSUSER=hardaker".
     (which is just like "make dist" above without first tagging things).

  8) Sign the packages:

     $ md5sum net-snmp-5.0.3.tar.gz > net-snmp-5.0.3.tar.gz.md5
     $ gpg -a --detach-sign net-snmp-5.0.3.tar.gz

  9) It's worth doing a round of testing directly with the tarred
     sources just to be sure.  I often haven't had time at this point,
     however.

 10) Upload the file to the sourceforge server:

     note: it's really hard to replace files on the file server with
     the exact same name as the previous file.  So, this should be the
     last step!  No turning back!  From here on out, we must rev the
     version number!

     0) upload the tar ball to ftp://upload.sf.net/incoming/
     a) go to the admin section of the net-snmp project home page
     b) click on "Edit/Release Files"
     c) click on "[Add Release]" for net-snmp
     d) Create a release like "5.0.3 sources"
     e) Click on the "Edit this release" button to add files to it.
     f) Do something similar to release binary files under "5.0.3
        binaries", for example.  [see below for creating them]

     WARNING:  The "Quick release file" mechanism, which is generally
     cool and saves steps *only* works if the release doesn't exist
     yet.  IE, don't use it twice to add two binary packages to "5.0.3
     binaries" for instance.  It will screw things up (I learned this
     the hard way).  You can do the first one using the Quick release
     mechanism, but the second has to be done using the "edit this
     release" button.

 11) Make a home-page news announcement.  Go to the net-snmp project
     page and click "news" and then "submit news".  It shouldn't need
     approval if you're a core developer (and you're logged in).

 12) Wait a week and if everything is ok, then submit a note to
     net-snmp-announce@lists.sf.net with a global announcement.  I
     wait a week to ensure there are no major problems before making
     a huge announcement.  I often make a immediate announcement to
     the users list to get some initial feedback.  If there are
     problems and another release is coming shortly, don't announce
     to the mailing list and announce the next one instead.  In the
     announcement include the NEWS snippet since the last release.

  12) bug Wes to update the freshmeat entries and the open source
      developers web page entries. 
      

***************************************************************************
CREATING BINARY DISTRIBUTIONS

  1) always build releases from a tarball, not from CVS.

  2) Add mib modules that are common.  Basically, add:

       host                      -- where supported.
       disman/event-mib
       smux

  3) use --with-defaults --with-syscontact="Unknown" 
     --with-syslocation="Unknown"

  4) when running make install, do it like:

     $ make install prefix=/some/path/to/home/ARCH/usr/local \
            exec_prefix=/some/path/to/home/ARCH/usr/local
    
  5) Tar it up:

     $ cd /some/path/to/home/ARCH
     $ tar czf net-snmp-5.0.3-ARCH.tar.gz usr/local

  6) upload and release, like you did for the source code but with a
     different package name for binaries (5.0.3 binaries).

***************************************************************************
CLEANING UP

  1) remove any official patches that apply to old releases?
     (we need to set a policy about whether to do this)

  2) delete any pre-release files from the download page using the
     admin interface

  3) remove older-binaries for older releases if you updated with newer
     binaries (don't remove any until there are newer ones for an 
     architecture available)

***************************************************************************
UPDATING WEB PAGE DOCUMENTS

  0) before doing any of this, make sure you have permissions set up
     properly on the web server so that files created become
     group-writable!!!

  1) NEWS at the top of the www.net-snmp.org webpage is auto-extracted
     (hourly) from the NEWS submissions on SF.  Don't worry about
     updating it.

  2) TBD

  3) some files (warning, assumes a htdocs/ -> net-snmp/htdocs link):
     foreach i (NEWS ChangeLog README* COPYING)
       scp $i www.net-snmp.org:htdocs/$i.txt
     end

