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 - check what you're about to commit with cvs -Q diff -r
  11 - preferably, keep an anonymous checkout around as well so you can
  12   immediately update and check if your changes work in a clean tree as well
  13
  14 Prerelease Period
  15 -----------------
  16 After a bit of development, people want a new release.  This generally happens
  17 when :
  18 - core developers get anxious to apply massive changes to the core bound
  19   to break everything
  20 - a few important plugins decide, as if by magic, to work again (avi, mad, ...)
  21 - Uraeus and thomasvs get tired of the general laziness
  22
  23 Also, this should only be allowed after passing a few sanity checks :
  24 - make distcheck should pass
  25 - rpms should build
  26 - FIXME: should debs be built here ? If so, how ?
  27
  28 At this time, we need to do a few prereleases for general checking by all
  29 interested developers.  To minimize the impact on the rest of the core hacking,
  30 we create a new CVS branch which will go through the pre-releases and finally
  31 contain the definitive tarball for that version.
  32
  33 TODO :
  34   - Decide on the next version number (major, minor or micro upgrade ?)
  35   - Get a fresh copy to do the necessary tests on
  36   - If this isn't on the stable branch (like for 0.6), then create a new branch;
  37     - with 0.3.3 as an example, tag is BRANCH-RELEASE-0_3_3
  38       cvs tag BRANCH-RELEASE-0_3_3-ROOT
  39       cvs tag -b BRANCH-RELEASE-0_3_3
  40       cvs update -r BRANCH-RELEASE-0_3_3
  41   - Set the nano to 2 (in configure.ac, AS_VERSION)
  42   - Do all updates/patches/changes for the release tarball in this branch
  43   - Think of a good codename for the release
  44   - create a new version dir in www/releases and add that to cvs
  45   - copy files from the last one to this new release dir
  46   - Start updating the release notes on the www cvs tree
  47   - Log in to sourceforge and run www-update.sh in the gstreamer root dir
  48   - depending on how the API has changed update the libtool versioning
  49     in configure.ac, AS_LIBTOOL
  50     (Look at the libtool info page about versioning for guidelines)
  51   - FIXME: autotools have latest config.{guess,sub}
  52            This is needed in order to support newer platforms.
  53            On Debian install the autotools-dev package to get these.
  54            Someone please add some more useful info here on how to do this
  55   - copy new supporting RPMS to the htdocs/redhat dir in various places,
  56     update README, and update symlinks to these packages in the release dir
  57   - while (IS_PRERELEASE)
  58     {
  59       - increase the nano number (starting with 2)
  60       - check out a fresh anonymous copy
  61         cvs -d:pserver:anonymous@cvs.gstreamer.sf.net:/cvsroot/gstreamer \
  62             co -rBRANCH-RELEASE-0_3_3 gstreamer
  63       - make distcheck, rpm build should pass, from a FRESH cvs tree
  64       - media tests should be done
  65       - source tarball should be installed and tested
  66       - rpms should be installed and tested
  67       - put up tarball for a day
  68     }
  69
  70
  71 Release Period
  72 --------------
  73 When we're satisfied with the prereleases, it's time to make the final tarball.
  74 It's very important that the tarball we put out is fully checked, works as
  75 planned, and generally is generated only ONCE by someone with a relatively
  76 clean (and reference) system.  We don't want to put out more than one tarball
  77 with the same name.
  78
  79 TODO :
  80   - give the latest prerelease another good testing
  81   - proofread the release notes (notice.php) and the index (index.php)
  82   - change the symlinks on the website :
  83     - change the releases/current symbolic link to point to the new release dir
  84     - change the releases/cvs symlink to point to the next release dir
  85   - run www-update.sh on sourceforge
  86   - make a text copy of the release notes to be included in the tarball :
  87     lynx -dump http://gstreamer.net/releases/current/notice.php?clean=1 > RELEASE
  88   - update web site docs
  89     - release-specific docs should go in CVS
  90     - change docs/current symlink
  91   - remove the nano version number in configure.ac, AS_VERSION
  92   - tag tree
  93     - policy is at http://gstreamer.net/dev/cvs.php
  94     - we stopped adding CODENAMES to cvs
  95       --> all of this is not done anymore
  96       - decide on a tag name : RELEASE-(VERSION)
  97       - tag; for example for 0.6.3 :
  98            cvs tag RELEASE-0_6_3
  99   - add tag
 100   - roll the tarball, build rpms
 101   - FIXME: update status table cvs status and then click on the release link
 102            http://gstreamer.net/admin.php is the portal to all of this
 103            where to get the password, what should we do here ?
 104
 105 Post-Release Period
 106 -------------------
 107 Time to bring the new version under the eyes of the public.
 108
 109 TODO :
 110   - FIXME: should we md5 the tarballs?
 111   - upload to sourceforge
 112       upload.sourceforge.net/incoming
 113       administer the release
 114
 115   - FIXME: announcements
 116     - gstreamer-{devel, announce} : a simple mail with RELEASE
 117     - freshmeat
 118     - linux-audio-dev (if it's a big release) : a simple mail with RELEASE
 119     - gnome lists (?)
 120     - lwn (if it's a big release)
 121   - Kick back, have a party, enjoy people coming in on IRC telling us how
 122     GStreamer rocks.
 123   - Later on, if necessary, merge back latest release branch to current dev
 124     branch (if patches to source were made)
 125     * change to a HEAD branch, make sure it's updated
 126     * cvs diff -R -r RELEASE-0_3_4-30SECONDFRENCHMAN
 127       gives a list of differences between head and release tag,
 128       stuff with > is how it's in HEAD, < is in the rel branch
 129
 130     * cvs update -j BRANCH-RELEASE-0_3_4
 131       merges the difference made in that branch to the current source
 132       this is what you want to use when merging back the branch
 133       resolve conflicts and commit
 134
 135 Some various random comments that might or might not make sense :
 136
 137 - Should work:
 138   * autoconf feature to allow building outside source dir
 139
 140 - Package version policy
 141   - Use major.minor.micro versioning
 142   - Before 1.0.0, Update micro until code and API are fairly stable,
 143     then update minor.
 144   - After 1.0.0,
 145     Update major when code and api hit new level of stability or major features.
 146     Update minor on API changes.
 147     Update micro on API-compatible changes.