docs/random/release

   1 GStreamer Release Policies (or: why we should become a country and pass laws)
   2 --------------------------
   3
   4 Development Period
   5 ------------------
   6 Development period is marked by having a fourth (nano) version number of 1.
   7 During development anything goes short of wiping the tree.
   8 Just try doing a few basic things :
   9 - make sure it builds for you !
  10 - preferably, keep an anonymous checkout around as well so you can
  11   immediately update and check if your changes work in a clean tree as well
  12
  13 Prerelease Period
  14 -----------------
  15 After a bit of development, people want a new release.  This generally happens
  16 when :
  17 - core developers get anxious to apply massive changes to the core bound
  18   to break everything
  19 - a few important plugins decide, as if by magic, to work again (avi, mad, ...)
  20 - thaytan or thomasvs get tired of being lazy.
  21
  22 Also, this should only be allowed after passing a few sanity checks :
  23 - make distcheck should pass
  24 - rpms should build
  25 - FIXME: should debs be built here ? If so, how ?
  26
  27 At this time, we need to do a few prereleases for general checking by all
  28 interested developers. The git modules that are in the process of being
  29 released are usually frozen for commits during that time, until the final
  30 release is made. We intentionally don't do releases in separate branches to
  31 make sure everyone is focused on testing the code that is about to be released.
  32
  33
  34 RELEASE PROCEDURE:
  35 -----------------
  36
  37 - www/bin/new-release is a release helper script.  It automates a lot of the
  38   tedious work.  Now releasing looks like this:
  39
  40 - before release:
  41   - make sure all blocker bugs for that release are fixed or deferred
  42   - make sure you have a local copy of all online files
  43   - run 'make download-po' to make sure translations in CVS are up-to-date,
  44     and then 'make update-po' in po/ (which will update the .pot template too
  45     and merge the changes into the .po files)
  46   - run 'make win32-update' where applicable
  47   - Make one or more prereleases
  48     - Make sure you've got the latest clean CVS of the module
  49     - Run bin/data-get in www/ to sync data from website
  50     - Bump the nano number to >= 2 (eg, first pre-release for
  51       0.10.12 is 0.10.11.2)
  52     - When releasing -base/-good/-ugly/-bad/gnonlin, make sure GST_REQ and
  53       GST_PBREQ are up-to-date. In particular, keep GST_REQ of the
  54       to-be-released -base module in sync with the core version that is to
  55       be released at the same time
  56     - Re-autogen if not in maintainer-mode (which you should be)
  57     - Update the changelog
  58         python common/gen-changelog.py > ChangeLog
  59     - Check (and fix if necessary) make distcheck
  60     - run 'make release' to build the tarballs
  61     - copy tarballs+md5 sums to the data/src/$module/pre/ dir
  62     - Run bin/data-put in www/ to sync the new tarballs to the website
  63     - Announce the availability of the new tarballs
  64     - Tell the translation project by sending an email to
  65       coordinator@translationproject.org, eg:
  66         Subject: gst-plugins-bad-0.10.5.2.pot available
  67         Tarball is at http://gstreamer.freedesktop.org/src/gst-plugins-bad/pre/gst-plugins-bad-0.10.5.2.tar.bz2
  68
  69 - prepare the release:
  70   - Make sure your www is up to date: Run bin/data-get in www/
  71   - Update the doap file to insert the new release info
  72   - Prepare the following in a text file for copy'n'paste purposes:
  73     - list of noteworthy changes / new features, check changelog or shortlog:
  74         - git log 1.0.98..
  75         - git shortlog 1.0.98..
  76         - wrap like this:
  77          <feature>added this and that</feature>
  78          <feature>foodemux now supports seek in twilight mode</feature>
  79     - list of API additions, two useful sources:
  80         - git diff 1.0.98.. win32/common/*.def \
  81             | grep "^+[^+]" | sed -e 's/[^a-z_]*/    <item>/' -e 's%$%</item>%'
  82         - git log 1.0.98.. --grep=API
  83         - wrap like this:
  84              <item>gst_new_func()</item>
  85              <item>gst_new_func_full()</item>
  86     - list of recently deprecated API, same as above:
  87              <item>gst_broken_func()</item>
  88   - in www, run bin/new-release (module) (version) (checkoutdir) (release name)
  89     - updates git
  90     - allows you to update versioning in configure.ac (don't forget to bump
  91       core/base requirements from prereleases to released version if needed)
  92     - rebuilds
  93     - updates ChangeLog
  94     - adds a new releases/module/version.xml file and lets you edit
  95       --> here you add/fix up the features (from ChangeLog) and check
  96           contributors
  97     - allows you to update NEWS file with snippets from RELEASE
  98       --> copy stuff
  99     - rebuilds docs for plugins
 100     - rolls release tarballs and puts them in the local www/data tree
 101     - uploads docs to website
 102     - commits changes to po files
 103     - shows you a diff for evaluation
 104
 105   - build packages to test
 106
 107 - release:
 108   - 'git commit -a' in the tree
 109   - tag tree. Tags should be GPG signed.
 110     Example: creating a 1.0.42 tag:
 111       Signed   : git tag -s -m 'Release 1.0.42' 1.0.42 (may prompt for passphrase)
 112       Unsigned : git tag -a -m 'Release 1.0.42' 1.0.42
 113     Check: 'git describe' should show '1.0.42' and 'git show 1.0.42' should
 114       show the PGP signature attached to the tag if it was signed.
 115   - bump nano number in configure.ac, commit
 116   - sync source and packages to website
 117     + run /bin/data-put in www
 118   - change versions in www/src/htdocs/entities.gst
 119   - add entry on website
 120     + Edit src/htdocs/news/news.xml (in a local checkout of the www git module)
 121       and add a new item at the bottom.
 122   - commit additions and push changes to the server
 123   - run bin/www-update in your www git module checkout. This will ssh into
 124     the server and update the website based on the changes you just pushed.
 125     This may require an entry for gstreamer.freedesktop.org in your
 126     ~/.ssh/config (e.g. in case your local username is different from your
 127     freedesktop.org username)
 128   - add versions and milestones in bugzilla
 129   - upload new core, -base and -good tarballs to gnome ftp
 130     + e.g:
 131        scp gstreamer-1.0.42.tar.xz master.gnome.org:
 132        ssh master.gnome.org
 133        ftpadmin install gstreamer-1.0.42.tar.xz
 134
 135   - Send release announcements to:
 136     gstreamer-devel@lists.freedesktop.org
 137     gstreamer-announce@lists.freedesktop.org
 138     kde-multimedia@kde.org
 139     gnome-multimedia@gnome.org
 140   - Update freshmeat with new releases (get Uraeus to do it)
 141
 142   - push release commit(s) to git repo
 143   - push new tag to git repo: git push origin tag 1.0.42
 144