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
109 - tag tree. Tags should be GPG signed.
110 Example: creating a 1.0.42 tag:
111 Signed : git tag -s -m 'Release 1.0.42' 1.0.42 (may prompt for passphrase)
112 Unsigned : git tag -a -m 'Release 1.0.42' 1.0.42
113 Check: 'git describe' should show '1.0.42' and 'git show 1.0.42' should
114 show the PGP signature attached to the tag if it was signed.
115 - bump nano number in configure.ac, commit
116 - sync source and packages to website
117 + run /bin/data-put in www
118 - change versions in www/src/htdocs/entities.gst
119 - add entry on website
120 + Edit src/htdocs/news/news.xml (in a local checkout of the www git module)
121 and add a new item at the bottom.
122 - commit additions and push changes to the server
123 - run bin/www-update in your www git module checkout. This will ssh into
124 the server and update the website based on the changes you just pushed.
125 This may require an entry for gstreamer.freedesktop.org in your
126 ~/.ssh/config (e.g. in case your local username is different from your
127 freedesktop.org username)
128 - add versions and milestones in bugzilla
129 - upload new core, -base and -good tarballs to gnome ftp
131 scp gstreamer-1.0.42.tar.xz master.gnome.org:
133 ftpadmin install gstreamer-1.0.42.tar.xz
135 - Send release announcements to:
136 gstreamer-devel@lists.freedesktop.org
137 gstreamer-announce@lists.freedesktop.org
138 kde-multimedia@kde.org
139 gnome-multimedia@gnome.org
140 - Update freshmeat with new releases (get Uraeus to do it)
142 - push release commit(s) to git repo
143 - push new tag to git repo: git push origin tag 1.0.42