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


CVS commit messages that generate auto-NEWS and auto-CHANGES
extractions should be formatted like the following examples.  The
extraction script is actually fairly lenient but you should try to
stick to the following formats only please.  Everything for a
particular entry must go on a single line, though it can be at the end
of a line.  All entries marked CHANGES will go into the CHANGES file.
All entries marked NEWS go into the NEWS and CHANGES file.

  NEWS: snmpd: I did something really cool to the agent
  CHANGES: snmptrapd: fixed something minor in snmptrapd
  NEWS: perl: PATCH: 123,456: Applied patches 123 and 456 to support perl6
  CHANGES: BUG: 13: Fixed bug 13 and secured the world at large against hackers
  NEWS: perl: PATCH: 123: from Robert: did something
  NEWS: perl: PATCH: 123: from "Robert Story": did something else

Text before the above formatting will be ignored.  Text until the next
newline or end is included in the description text.  Description text
will be auto-line-wrapped.  See the dist/extractnews file for nasty
regexp details.

Valid tokens can technically be anything, but based on past history
they should be one of:

  snmpd
  snmptrapd
  snmplib
  apps
  snmpusm, snmpget, ...           # if it applies to just one
  building
  documentation
  perl
  mib2c
  Linux, Solaris, Win32, FreeBSD, OpenBSD
  misc

The release maintainer will still need to edit and classify these
further, of course, but this merely provides a start for them.



***************************************************************************
**** 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:

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

     $ cvs update

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

     Change the libtool version information in Makefile.top.

      - If any interfaces/structures have been removed or changed since the
        last update, increment current, and set age and revision to 0. Stop!

      - If any interfaces have been added since the last public release, then
        increment current and age, and set revision to 0. Stop!

      - If the source code has changed at all since the last update,
        then increment revision (c:r:a becomes c:r+1:a).

      Note: maintenance releases (eg 5.2.x) should never have changes
            that would require current to be incremented.

     Update these variables 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 :-/

  3) Change the configure script version number.  This isn't
      autochanged either.  The line to change looks like this:

        AC_INIT([Net-SNMP], [5.1.2], [net-snmp-coders@lists.sourceforge.net])

      And then run autoconf and autoheader, as well as a CVS commit.

  4) 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=IPX' --enable-ipv6              \
                   --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

  5) 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).

  6) Make sure installing works.

     $ make install

  7) 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 for illegal constructs in various places

        $ make checks

        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.

        It will also check for some illegal GNU make specific
        constructs in makefiles.

     b) Make the doxygen extracted manual pages.

        !!! Edit version number in doxygen.conf file.
        $ 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 5.x:

             $ make distdepend

           For 4.x:

             $ make makefileindepend

           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 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.

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

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

  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 --follow-only trunk --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-ancestors \
             --no-hide-branch-additions --no-wrap -S

          [if you get errors from --no-hide-branch-additions or
           --no-ancestors, make you you have a recent version of cvs2cl.
           Latest as of 1/2005 is 2.58. Available at
                http://www.red-bean.com/cvs2cl/cvs2cl.pl

       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.  Watch the diff outputs scroll by to
           make sure it didn't mess up.
        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:

     Non Wes/Robert:
     $ md5sum net-snmp-5.0.3.tar.gz > net-snmp-5.0.3.tar.gz.md5

     Wes/Robert:
     $ gpg -u net-snmp-admin -a --detach-sign net-snmp-5.0.3.tar.gz

     (to get Wes/Robert to sign them, send him the binaries and the
     md5 sum.)

  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'-14')  For pre-releases, submit a note to net-snmp-coders with
     an announcement and call for testing.  For release-candidates,
     a similar announcement should go to net-snmp-users instead.

 11) For full releases, announce the new release on net-snmp-users,
     including the NEWS snippet of significant changes since the last
     release.  Also announce it as a news item on the project home-page.
     Go to 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 to ensure that there are no major problems with the
     release, and then (assuming everything is ok) submit a note to
     net-snmp-announce@lists.sf.net with a global announcement.
        If there are problems and another release is planned to fix
     them, don't announce the broken version - wait for the updated
     one instead.

 13) Once the release has been formally advertised on the announce
     list, start bugging Wes to update the freshmeat entries and the
     open source developers web page entries. 

 14) Update the following htdocs files:

     htdocs/dev/schedule.html
     htdocs/download/index.html

     and, ideally, the IRC topic.

 15) For the latest final release, also update the following htdocs
     file:

     htdocs/page-top.html

 16) For a major new-feature release (eg 5.3), create the patches
     branch immediately after the final release.

	$ cvs rtag -r Ext-5-3 -b V5-3-patches net-snmp

 17) Update the official patches tracker set

     - the "official patches" tracker should have all patches marked
       for the current branches as priority 9.  The previous release on
       any given branch should be downgraded to 5, and all older than
       that should be downgraded to 1 and closed.

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

  0) Always REMOVE ALL PREVIOUS INSTALLS FIRST, then do a make install
     from the tar-ball extracted sources and *THEN* rebuild all
     binaries again.  This ensures that everything (especially perl
     modules) are properly linked against the right libraries.

  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).

  7) RPMS [do this in main line even if its for a patch branch]:
     $ cd dist
     $ cp ../net-snmp-5.0.8.tar.gz rpm/SOURCES
     $ make RELEASE=1
     
     This should put multiple binary rpm files in:
       dist/rpm/RPMS/i386/
     And one source RPM in:
       dist/rpm/SRPMS/

     *** These files need to be renamed to include the OS version.

         EG: ...i386.rpm needs to become ...fc5.i386.rpm

***************************************************************************
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

