HOWTO-RELEASE

HOWTO-RELEASE:

Notes on releasing.

0. Make sure that you have current stable FSF releases of autoconf,
   automake, and libtool packages installed under a common
   installation prefix and that these tools are in your executable
   search path prior to any other installed versions.  Versions
   delivered with Linux may be altered (or very stale) so it is best
   to install official FSF releases. GNU 'm4' 1.4.16 or later is
   needed in order to avoid bugs in m4. These packages may be
   downloaded from the following ftp locations:

     m4       - https://ftpmirror.gnu.org/m4
     autoconf - https://ftpmirror.gnu.org/autoconf
     automake - https://ftpmirror.gnu.org/automake
     libtool  - https://ftpmirror.gnu.org/libtool

   It is recommended to install m4 (if necessary) before autoconf,
   since the later requires the former.

   At the time this is last updated, the current versions are Autoconf
   2.73, Automake 1.19, Libtool 2.6.2, and m4 1.4.21.

   Release builds should only be done on a system with a functioning
   and correctly set system clock and on a filesystem which accurately
   records file update times.  Use of GNU make is recommended.

1. Commit any unsaved changes.

2. Use gnulib's 'gitlog-to-changelog' script to add new (since the
   last release) entries to the traditional ChangeLog file.  This
   script may be retrieved similar to:

     git clone https://git.savannah.gnu.org/git/gnulib.git
     cd gnulib/build-aux/
     cp gitlog-to-changelog myscriptdir/

   where 'myscriptdir' is where you put useful scripts and is in your
   executable search path.

   Take note of the most recent change note time stamp and use that as
   the starting point.  Concatenate the old logs to the new logs.  The
   added logs may be used to help produce the release notes (in next
   step).  For example:

     gitlog-to-changelog --since=`head -n 1 ChangeLog | sed -e 's/ .*//g'` --append-dot > ChangeLog.added
     printf "\n" >> ChangeLog.added
     cat ChangeLog.added ChangeLog > ChangeLog.new
     mv ChangeLog.new ChangeLog
     rm ChangeLog.added

3. Create doc/releases/vX.X.rst and add it to git with 'git add doc/releases/vX.X.rst'.
   Update doc/releases/index.rst to point to the new file
   Take ChangeLog entries and rst-ify in there.
   Easiest thing to do is take doc/releases/vX.(X-1).rst and use it as a template.

4. Add vX.X.rst file to the list of 'rst_sources' files in the doc/Makefile.am.

5. Update "Latest Stable Release" in doc/index.rst.

6. Increment the release version in configure.ac.  Put 'alpha' or
   'beta' after the version, if applicable.  For example:

     4.0.0
      or
     4.0.0beta7

   Version should be updated in two places: in the second argument of the
   AC_INIT macro and in LIBTIFF_xxx_VERSION variables.

7. Update library ELF versioning in configure.ac (LIBTIFF_CURRENT,
   LIBTIFF_REVISION, and LIBTIFF_AGE).  These numbers have nothing to
   do with the libtiff release version numbers.

   Note that as of libtiff 4.X, proper ELF versioning is used so
   please follow the rules listed in configure.ac.  At a bare minimum,
   you should increment LIBTIFF_REVISION for each release so that
   installed library files don't overwrite existing files.  If APIs
   have been added, removed, or interface structures have changed,
   then more care is required.

8. Add an entry to Changelog similar to:

     * libtiff 4.0.0 released.

9. In the source tree do

     ./autogen.sh

   This step may be skipped if you have already been using a
   maintainer build with current stable autoconf, automake, and
   libtool packages.  It is only needed when updating tool versions
   and should really be performed far in advance of producing a
   release for adequate verification.

   The 'autogen.sh' script may optionally update the
   config/config.guess and config/config.sub files in the source
   tree.  In order for this happen, use

     git clone https://git.savannah.gnu.org/git/gnulib.git

   in the parent of the libtiff directory so that 'gnulib' is adjacent
   to 'libtiff'.  Given that hardware/system permutations are
   often updated, it is worth ensuring that the files updated by
   'autogen.sh' are current by updating from the gnulib versions.

10. It is recommended (but not required) to build outside of the source
   tree so that the source tree is kept in a pristine state.  This
   also allows sharing the source directory on several networked
   systems.  For example:

     mkdir libtiff-build
     cd libtiff-build
     /path/to/libtiff/configure --enable-maintainer-mode

   otherwise do

     ./configure --enable-maintainer-mode

11. In the build tree do

     make release

   This will update "RELEASE-DATE", "VERSION" in the source tree,
   and libtiff/tiffvers.h in the build tree.

12. In the source tree, verify that the version info in RELEASE-DATE,
    VERSION is right.
    In the build tree, verify that the version info in
    libtiff/tiffvers.h is right.

13. In the build tree do

      make
      make distcheck

    If 'make distcheck' fails, then correct any issues until it
    succeeds.

    Two files with names tiff-version.tar.gz and tiff-version.zip will
    be created in the top level build directory.

14. In the source tree do

      'git status', 'git add .', 'git commit' and 'git push'

15. In the source tree, create a signed tag

      git tag -s v4.0.0 -m "Create tag for v4.0.0"

    (or the appropriate name for the release)

    and push it to "origin" (if "origin" points to the official repository)

      git push origin v4.0.0

16. Sign the release files in the build tree using your private key

      export GPG_TTY=$(tty)
      for file in tiff-*.tar.gz tiff-*.tar.xz tiff-*.zip ; do \
        gpg2 --output ${file}.sig --detach-sig $file ; \
      done

      for file in tiff-*.tar.gz tiff-*.tar.xz tiff-*.zip ; do \
        gpg2 --verify ${file}.sig $file ; \
      done

17. Copy release packages from the build tree to the
    ftp.remotesensing.org ftp site.

      scp tiff-*.tar.gz tiff-*.tar.gz.sig tiff-*.tar.xz tiff-*.tar.xz.sig tiff-*.zip tiff-*.zip.sig \
         bfriesen@upload.osgeo.org:/osgeo/download/libtiff

18. Create a gitlab release at https://gitlab.com/libtiff/libtiff/-/releases

19. Announce to list: tiff@lists.osgeo.org