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 NOTE:  Due to the way that the regression tests work they will usually fail
  21 when run on a different machine (different CPU type for example) than what
  22 the test suite golden files were generated on.  To let the rest of 'distcheck'
  23 complete, use this:
  24
  25 setenv GERBV_MAGIC_TEST_SKIP yes
  26
  27 or under ksh/sh
  28
  29 GERBV_MAGIC_TEST_SKIP=yes
  30 export GERBV_MAGIC_TEST_SKIP
  31
  32 To make a gerbv release do the following:
  33
  34 =)      Review the BUGS file and make sure it is up to date.
  35
  36 =)      # make sure it builds and makes distfiles ok:
  37         ./autogen.sh
  38         ./configure --enable-maintainer-mode  --disable-update-desktop-database
  39         gmake maintainer-clean
  40         ./autogen.sh
  41         ./configure --disable-update-desktop-database
  42         gmake distcheck
  43
  44 =)      commit and push any changes which were needed to fix 'distcheck' problems.
  45         Of course if the changes aren't related then they should be committed in
  46         multiple commits.
  47
  48         git commit <files>
  49         git push <files>
  50
  51 =)      Read the section in src/Makefile.am about the shared library versioning
  52         and make sure we have done the right thing.  Check in src/Makefile.am
  53         if needed.  This is critical.  The version *will* change with every release
  54         if *any* changes have been made to the sources for libgerbv.  src/Makefile.am
  55         has specific rules for how the versioning works.
  56
  57 =)      if there were any new developers added then update the
  58         ./utils/umap file.
  59
  60 =)      update the ChangeLog with 'git2cl'.
  61         ./utils/git2cl -O > ChangeLog
  62
  63 =)      update the NEWS file with some sort of release notes.
  64         I typically try to condense what I see in ChangeLog
  65         You can find the number of commits with something like
  66
  67             awk '/^2008-11-28/ {print "Changes: " c ; exit} /^20[01][0-9]/ {c++}' ChangeLog
  68
  69         Commit and push NEWS and ChangeLog:
  70
  71         git commit NEWS ChangeLog
  72         git push
  73
  74 =)      if this is a major release, then tag and branch:
  75
  76         1. Create the release branch and push to the remote repository
  77                 git branch gerbv-2-4
  78                 git push origin gerbv-2-4
  79
  80         2. On the trunk, update configure.ac to update the version.
  81            The rules for versioning is that we append uppercase
  82            letters to the branch version.
  83
  84            For example 2.4A after creating the gerbv-2-4 branch
  85                 git checkout master
  86                 vi configure.ac
  87                 git commit configure.ac
  88                 git push
  89
  90         3. On the release branch, update configure.ac to update the
  91            version.  On a new branch, add a 0RC1 to the teeny number.
  92            for example 2.4.0RC1.
  93
  94                 git checkout gerbv-2-4
  95                 vi configure.ac
  96                 git commit configure.ac
  97                 git push
  98
  99            NOTE:  if you are not going to do a release candidate step,
 100                   then skip this push and directly put in the release
 101                   version.
 102
 103         3a.Ask users to test the branch.
 104
 105         4. When the release branch is ready to go,  update configure.ac to
 106            set the final release version.  The first version from a
 107            branch has 0 for the teeny version.  For example, 2.4.0.
 108
 109                 git checkout gerbv-2-4
 110                 vi configure.ac
 111                 git commit configure.ac
 112                 ./autogen.sh
 113                 git commit -a  # after we expunge all generate files from git, we can skip this one
 114                 git push
 115
 116            Next tag the release.
 117
 118                 git tag -a gerbv-2-4-RELEASE
 119                 git push --tags
 120
 121            Update the version on the branch to 2.4.1RC1
 122                 git checkout gerbv-2-4
 123                 vi configure.ac
 124                 git commit configure.ac
 125                 git push
 126
 127            Update to the tagged released sources and build tarballs
 128                 git checkout gerbv-2-4-RELEASE
 129                 ./autogen.sh
 130                 ./configure --enable-maintainer-mode --disable-update-desktop-database
 131                 gmake maintainer-clean
 132                 ./autogen.sh
 133                 ./configure --disable-update-desktop-database
 134                 gmake distcheck
 135
 136            If teeny version bumps are made for a bug fix, then the tag name
 137            should be gerbv-2-4-PATCH001 for gerbv-2.4.1,
 138            gerbv-2-4-PATCH002 for gerbv-2.4.2, etc.
 139
 140         5. Create checksums
 141
 142                 openssl md5 gerbv-2.4.0.tar.gz > gerbv-2.4.0.cksum
 143                 openssl rmd160 gerbv-2.4.0.tar.gz >> gerbv-2.4.0.cksum
 144                 openssl sha1 gerbv-2.4.0.tar.gz >> gerbv-2.4.0.cksum
 145
 146         6. Create a new file release for the package "gerbv" with a release name of
 147            "gerbv-2.4.0" (for gerbv-2.4.0).  Do this by logging into www.sourceforge.net
 148            and then navigating to
 149
 150            https://sourceforge.net/projects/gerbv  (you must be logged in to sourceforge)
 151
 152            Upload the .tar.gz, .cksum, and if you built one, the windows installer.
 153
 154            Once you have completed the file uploads return to the edit releases page, check
 155            the radio buttons next to the uploaded files and click the "Add Files..." button.
 156
 157            In the "Step 3:  Edit Files in this Release" section, set the following:
 158                 For file types:
 159                         .tar.gz  -  any / source .gz
 160                         .cksum   -  Platform Independent / Other Source File
 161                         .exe     -  i386 / .exe (32-bit Windows)
 162
 163            You will have to click "update" for each file as you go.
 164
 165            In the "Step 4:  Email Release Notice" section, check the "I'm sure"
 166            radio button and click the "Send Notice" button.
 167
 168          7. Have a project admin go to the Admin->File Releases page and then
 169             follow the "Create/Edit Download page" to change the default download
 170             file to the new release.
 171
 172          8. Return to your regularly scheduled trunk development
 173
 174                 git checkout master
 175
 176 =)      if this is a patch release (2.4.1 for example), then simply
 177         make desired changes to the branch:
 178
 179                 git checkout gerbv-2-4
 180                 # make changes
 181                 git commit
 182                 git tag -a gerbv-2-4-PATCH001
 183                 git push
 184
 185
 186