README-release.txt

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