README-release.txt

   1 #!/bin/sh
   2 #
   3 # $Id$
   4 #
   5
   6 This documents what is done to create a gerbv release.  The releases now
   7 are done by branching the sources, fixing up the release version number
   8 in the branch and then tagging the release branch sources.  The motivation
   9 for a branch rather than a tag is to make it easier to deal with setting
  10 the release version number in the documentation, distfile, and the
  11 about dialog box.
  12
  13 Note that the gyrations with maintainer-clean and another build are to
  14 be sure that all the correct versions numbers end up in the files.
  15
  16 After following the steps below,
  17 upload the 'gerbv-$VERSION.tar.gz' file to the sourceforge file release system
  18
  19
  20 To make a gerbv release do the following:
  21
  22 =)      Review the BUGS file and make sure it is up to date.
  23
  24 =)      # make sure it builds and makes distfiles ok:
  25         ./autogen.sh
  26         ./configure --enable-maintainer-mode
  27         gmake maintainer-clean
  28         ./autogen.sh
  29         ./configure
  30         gmake distcheck
  31
  32 =)      cvs ci
  33
  34 =)      Read the section in src/Makefile.am about the shared library versioning
  35         and make sure we have done the right thing.  Check in src/Makefile.am
  36         if needed.  This is critical.  The version *will* change with every release
  37         if *any* changes have been made to the sources for libgerbv.  src/Makefile.am
  38         has specific rules for how the versioning works.
  39
  40 =)      update the NEWS file with some sort of release notes.
  41         Check in changes
  42
  43 =)      if there were any new developers added then update the
  44         ./utils/umap file.
  45
  46 =)      update the ChangeLog with 'cvs2cl.pl'.  Check in changes.
  47         ./utils/cvs2cl.pl -U ./utils/umap
  48
  49 =)      if this is a major release, then tag and branch:
  50
  51         1. Tag the base of the release branch
  52                 cvs tag gerbv-2-0-base
  53
  54         2. Create the release branch
  55                 cvs tag -R -b -r gerbv-2-0-base gerbv-2-0
  56
  57         3. On the trunk, update configure.ac to update the version.
  58            The rules for versioning is that we append uppercase
  59            letters to the branch version.
  60
  61                 for example 2.0A after creating the gerbv-2-0 branch
  62                 cvs update -PdA
  63                 vi configure.ac
  64                 cvs ci configure.ac
  65
  66         4. On the release branch, update configure.ac to update the
  67            version.  On a new branch, add a 0RC1 to the teeny number.
  68
  69                 for example 2.0.0RC1.
  70                 cvs update -PdA -r gerbv-2-0
  71                 vi configure.ac
  72                 cvs ci configure.ac
  73
  74         4a.Ask users to test the branch.
  75
  76         5. When the release branch is ready to go,  update configure.ac to
  77            set the final release version.  The first version from a
  78            branch has 0 for the teeny version.  For example, 2.0.0.
  79            Next tag the release.
  80                 cvs update -PdA -r gerbv-2-0
  81                 vi configure.ac
  82                 cvs ci configure.ac
  83                 cvs tag -R -r gerbv-2-0 gerbv-2-0-RELEASE
  84
  85            Update the version on the branch to 2.0.1RC1
  86                 cvs update -PdA -r gerbv-2-0
  87                 vi configure.ac
  88                 cvs ci configure.ac
  89
  90            Update to the tagged released sources and build tarballs
  91                 cvs update -PdA -r gerbv-2-0-RELEASE
  92                 ./autogen.sh
  93                 ./configure --enable-maintainer-mode
  94                 gmake maintainer-clean
  95                 ./autogen.sh
  96                 ./configure
  97                 gmake distcheck
  98
  99            If teeny version bumps are made for a bug fix, then the tag name
 100            should be gerbv-2-0-PATCH001 for gerbv-2.0.1,
 101            gerbv-2-0-PATCH002 for gerbv-2.0.2, etc.
 102
 103         7. Create checksums
 104
 105                 openssl md5 gerbv-2.0.0.tar.gz > gerbv-2.0.0.cksum
 106                 openssl rmd160 gerbv-2.0.0.tar.gz >> gerbv-2.0.0.cksum
 107                 openssl sha1 gerbv-2.0.0.tar.gz >> gerbv-2.0.0.cksum
 108
 109         8. Upload the .tar.gz, and .cksum files to
 110            ftp://upload.sourceforge.net/incoming/
 111
 112         9. Create a new file release for gerbv with a release name of
 113            "gerbv-2.0.0" (for gerbv-2.0.0).
 114
 115                 For file types:
 116                         .tar.gz  -  any / source .gz
 117                         .cksum   -  Platform Independent / Other Source File
 118
 119         10. Return to your regularly scheduled trunk development
 120                 cvs update -PdA
 121
 122 =)      if this is a patch release (2.0.1 for example), then simply
 123         make desired changes to the branch:
 124
 125                 cvs update -PdA -r gerbv-2-0
 126                 # make changes
 127                 cvs ci
 128
 129         update the version for the release
 130                 vi configure.ac
 131                 cvs ci configure.ac
 132
 133         tag the release
 134                 cvs tag -R -r gerbv-2-0 gerbv-2-0-PATCH001
 135
 136         update the version on the branch to 2.0.2RC1
 137                 vi configure.ac
 138                 cvs ci configure.ac
 139
 140
 141         update to the tagged release sources and build tarballs
 142                 cvs update -PdA -r gerbv-2-0-PATCH001
 143                 ./autogen.sh
 144                 ./configure --enable-maintainer-mode
 145                 gmake maintainer-clean
 146                 ./autogen.sh
 147                 ./configure
 148                 gmake distcheck
 149
 150