1 GStreamer Release Policies (or: why we should become a country and pass laws)
2 --------------------------
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
15 After a bit of development, people want a new release. This generally happens
17 - core developers get anxious to apply massive changes to the core bound
19 - a few important plugins decide, as if by magic, to work again (avi, mad, ...)
20 - thaytan or thomasvs get tired of being lazy.
22 Also, this should only be allowed after passing a few sanity checks :
23 - make distcheck should pass
25 - FIXME: should debs be built here ? If so, how ?
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.
37 - www/bin/new-release is a release helper script. It automates a lot of the
38 tedious work. Now releasing looks like this:
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
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
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:
75 - git shortlog 1.0.98..
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
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)
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)
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
97 - allows you to update NEWS file with snippets from RELEASE
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
105 - build packages to test
108 - 'git commit -a' in the tree
110 for example for 1.0.42 :
111 git tag -a -m 'Release 1.0.42' 1.0.42
112 Make sure to use the -a option to create an *annotated* tag: 'git describe'
114 - bump nano number in configure.ac, commit
115 - sync source and packages to website
116 + run /bin/data-put in www
117 - change versions in www/src/htdocs/entities.gst
118 - add entry on website
119 + Edit src/htdocs/news/news.xml (in a local checkout of the www git module)
120 and add a new item at the bottom.
121 - commit additions and push changes to the server
122 - run bin/www-update in your www git module checkout. This will ssh into
123 the server and update the website based on the changes you just pushed.
124 This may require an entry for gstreamer.freedesktop.org in your
125 ~/.ssh/config (e.g. in case your local username is different from your
126 freedesktop.org username)
127 - add versions and milestones in bugzilla
128 - upload new core, -base and -good tarballs to gnome ftp
130 scp gstreamer-1.0.42.tar.xz master.gnome.org:
132 ftpadmin install gstreamer-1.0.42.tar.xz
134 - Send release announcements to:
135 gstreamer-devel@lists.freedesktop.org
136 gstreamer-announce@lists.freedesktop.org
137 kde-multimedia@kde.org
138 gnome-multimedia@gnome.org
139 - Update freshmeat with new releases (get Uraeus to do it)
141 - push release commit(s) to git repo
142 - push new tag to git repo: git push origin tag 1.0.42