summaryrefslogtreecommitdiff
path: root/docs/random/release
blob: 773cb7a2d16dc70a71f1c1bb81f98fd04b9411d8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
GStreamer Release Policies (or: why we should become a country and pass laws)
--------------------------

Development Period
------------------
Development period is marked by having a fourth (nano) version number of 1.
During development anything goes short of wiping the tree.
Just try doing a few basic things :
- make sure it builds for you !
- check what you're about to commit with cvs -Q diff -r
- preferably, keep an anonymous checkout around as well so you can
  immediately update and check if your changes work in a clean tree as well

Prerelease Period
-----------------
After a bit of development, people want a new release.  This generally happens
when :
- core developers get anxious to apply massive changes to the core bound
  to break everything
- a few important plugins decide, as if by magic, to work again (avi, mad, ...)
- thaytan or thomasvs get tired of being lazy.

Also, this should only be allowed after passing a few sanity checks :
- make distcheck should pass
- rpms should build
- FIXME: should debs be built here ? If so, how ?

At this time, we need to do a few prereleases for general checking by all
interested developers.  To minimize the impact on the rest of the core hacking,
we create a new CVS branch which will go through the pre-releases and finally
contain the definitive tarball for that version.

RELEASE PROCEDURE:
-----------------

- www/bin/new-release is a release helper script.  It automates a lot of the
  tedious work.  Now releasing looks like this:

- before release:
  - make sure all blocker bugs for that release are fixed or deferred
  - make sure you have a local copy of all online files
  - run 'make download-po' to make sure translations in CVS are up-to-date,
    and then 'make update-po' in po/ (which will update the .pot template too
    and merge the changes into the .po files)
  - Make one or more prereleases
    - Make sure you've got the latest clean CVS of the module
    - Run bin/data-get in www/ to sync data from website
    - Bump the nano number to > 2 (eg, first pre-release for 
      0.10.12 is 0.10.11.2)
    - When releasing -base/-good/-ugly/-bad/gnonlin, make sure GST_REQ and
      GST_PBREQ are up-to-date. In particular, keep GST_REQ of the
      to-be-released -base module in sync with the core version that is to
      be released at the same time
    - Re-autogen if not in maintainer-mode (which you should be)
    - Update the changelog
        python common/gen-changelog.py > ChangeLog
    - Check (and fix if necessary) make distcheck
    - run 'make release' to build the tarballs
    - copy tarballs+md5 sums to the data/src/$module/pre/ dir
    - Run bin/data-put in www/ to sync the new tarballs to the website
    - Announce the availability of the new tarballs
    - Tell the translation project by sending an email to 
      coordinator@translationproject.org, eg:
        Subject: gst-plugins-bad-0.10.5.2.pot available
        Tarball is at http://gstreamer.freedesktop.org/src/gst-plugins-bad/pre/gst-plugins-bad-0.10.5.2.tar.bz2 

- prepare the release:
  - Make sure your www is up to date: Run bin/data-get in www/
  - Update the doap file to insert the new release info
  - bin/new-release (module) (version) (checkoutdir) (release name)
    - updates cvs
    - allows you to update versioning in configure.ac
    - rebuilds
    - updates ChangeLog
    - adds a new releases/module/version.xml file and lets you edit
      --> here you add/fix up the features (from ChangeLog) and check
	  contributors
    - allows you to update NEWS file with snippets from RELEASE
      --> copy stuff
    - rebuilds docs for plugins
    - rolls release tarballs and puts them in the local www/data tree
    - uploads docs to website
    - commits changes to po files
    - shows you a diff for evaluation

  - build packages to test

- release:
  - 'git commit -a' in the tree
  - tag tree
    for example for 0.6.3 :
           git tag -a RELEASE-0.6.3
  - bump nano number in configure.ac, commit
  - sync source and packages to website
    + run /bin/data-put in www
  - change versions in www/src/htdocs/entities.gst
  - add entry on website
    + Edit src/htdocs/news/news.xml and add a new item at the bottom.
  - commit additions to website
  - add versions and milestones in bugzilla
  - upload new core, -base and -good tarballs to gnome ftp
    + e.g:
       scp gstreamer-0.10.42.tar.gz master.gnome.org:
       ssh master.gnome.org
       install-module gstreamer-0.10.42.tar.gz

  - Send release announcements to:
    gstreamer-devel@lists.sourceforge.net gstreamer-announce@lists.sourceforge.net kde-multimedia@kde.org gnome-multimedia@gnome.org
  - Update freshmeat with new releases (get Uraeus to do it)