docs/random/release

   1 maybe we should be doing releases on branches from the trunk so that the package
   2 version in CVS can always be date-generated and core hacking isn't discouraged
   3 during the release cycle.
   4
   5 Release TODO
   6 ------------
   7
   8 * make distcheck should pass
   9 * rpms should build
  10 * debs should build
  11
  12 Packaging issues will hopefully be less difficult in the future as the build
  13 system stabilizes.
  14
  15 * after a release, we move in cvs mode and use a .1 nano version number
  16
  17 * close to the next release, we make prereleases by upping the nano version
  18
  19 * update web site release notes
  20
  21 * add release notes to cvs -- why?
  22
  23 * take a FRESH cvs checkout
  24
  25 * make distcheck should pass
  26
  27 * test suite should pass
  28
  29 * rpms should build and install
  30
  31 * autotools have latest config.{guess,sub}
  32   This is needed in order to support newer platforms.
  33   On Debian install the autotools-dev package to get these.
  34
  35 * depending on how the API has changed update the libtool versioning
  36   in configure.ac.  Look at the libtool info page about versioning for
  37   guidelines.
  38
  39 * update package version
  40
  41 * roll a preliminary distribution tarball, make sure that it installs fine,
  42 registers fine, runs the media tests fine, and uninstalls as well
  43
  44 * tag tree
  45   http://gstreamer.net/dev/cvs.php
  46   add tag to above page
  47
  48 * relink current and cvs in the redhat dir and copy the symlinks from the
  49   current to the new release treee
  50
  51 * update web site release notes: added to cvs
  52   - change the releases/current symbolic link
  53   - text version of release announcement can be made from
  54     lynx -dump http://gstreamer.net/releases/current/notice.php?clean=1
  55
  56 * update web site docs
  57   - release-specific docs should go in CVS
  58   - change docs/current symlink
  59
  60 * update status table cvs status and then click on the release link
  61   http://gstreamer.net/admin.php is the portal to all of this
  62
  63 * update web site news items for release
  64   again, the admin.php page
  65
  66 * upload to sourceforge
  67   - should we md5 the tarballs?
  68
  69 * announce to:
  70   freshmeat
  71   gstreamer-{devel, announce}
  72   linux-audio-dev (if it's a big release)
  73   gnome lists (?)
  74   lwn (if it's a big release)
  75
  76
  77 Should work:
  78
  79 * autoconf feature to allow building outside source dir
  80
  81
  82
  83 Package version policy
  84 ----------------------
  85
  86 Use major.minor.micro versioning
  87
  88 Before 1.0.0
  89
  90 Update micro until code and API are fairly stable, then update minor.
  91
  92
  93 After 1.0.0
  94
  95 Update major when code and api hit new level of stability or major features.
  96 Update minor on API changes.
  97 Update micro on API-compatible changes.