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   - bin/new-release (module) (version) (checkoutdir) (release name)
  73     - updates cvs
  74     - allows you to update versioning in configure.ac
  75     - rebuilds
  76     - updates ChangeLog
  77     - adds a new releases/module/version.xml file and lets you edit
  78       --> here you add/fix up the features (from ChangeLog) and check
  79           contributors
  80     - allows you to update NEWS file with snippets from RELEASE
  81       --> copy stuff
  82     - rebuilds docs for plugins
  83     - rolls release tarballs and puts them in the local www/data tree
  84     - uploads docs to website
  85     - commits changes to po files
  86     - shows you a diff for evaluation
  87
  88   - build packages to test
  89
  90 - release:
  91   - 'git commit -a' in the tree
  92   - tag tree
  93     for example for 0.6.3 :
  94            git tag -a -m 'Release 0.6.3' RELEASE-0.6.3
  95     Make sure to use the -a option to create an *annotated* tag: 'git describe'
  96     should show 'RELEASE-0.6.3'
  97   - bump nano number in configure.ac, commit
  98   - sync source and packages to website
  99     + run /bin/data-put in www
 100   - change versions in www/src/htdocs/entities.gst
 101   - add entry on website
 102     + Edit src/htdocs/news/news.xml and add a new item at the bottom.
 103   - commit additions to website
 104   - add versions and milestones in bugzilla
 105   - upload new core, -base and -good tarballs to gnome ftp
 106     + e.g:
 107        scp gstreamer-0.10.42.tar.gz master.gnome.org:
 108        ssh master.gnome.org
 109        install-module gstreamer-0.10.42.tar.gz
 110
 111   - Send release announcements to:
 112     gstreamer-devel@lists.sourceforge.net gstreamer-announce@lists.sourceforge.net kde-multimedia@kde.org gnome-multimedia@gnome.org
 113   - Update freshmeat with new releases (get Uraeus to do it)
 114