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 - 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
16 After a bit of development, people want a new release. This generally happens
18 - core developers get anxious to apply massive changes to the core bound
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
23 Also, this should only be allowed after passing a few sanity checks :
24 - make distcheck should pass
26 - FIXME: should debs be built here ? If so, how ?
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.
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 - update your local copy to the branch:
41 cvs update -r BRANCH-RELEASE-0_3_3
42 - Set the nano to 2 (in configure.ac, AS_VERSION)
43 - If this is a release candidate for a new major version, override
44 MAJOR/MINOR in configure.ac
45 - Do all updates/patches/changes for the release tarball in this branch
46 - Think of a good codename for the release
47 - Check the bug lists:
48 - The idea is to have all bugs for this milestone listed as fixed
49 - Check all of the bug reports with this version as a milestone, and verify
50 that these bugs are fixed, or reassign to a later milestone if not
51 - Check later milestone bugs, and if any of them are fixed, reassign to
53 - Check the list of bugs resolved with milestone HEAD, which should be
54 assigned to an actual milestone
55 - create a new $(version).xml file in www/src/htdocs/releases/$(module)
57 - Start updating the release notes on the www cvs tree
58 - create the base xml file in www/htdocs/releases/$/module)/$(version).xml
59 - grepping ChangeLog for contributors:
60 grep "<.*>" ChangeLog | perl -i -p -e 's@\d*-\d*-\d*\s*(.*)\s*<.*$@$1@' | sort | uniq
61 - use www/bin/bugzilla (module) (version) to get an xml list of the
62 bugs fixed in this version, and add it to the release .xml
63 - depending on how the API has changed update the libtool versioning
64 in configure.ac, AS_LIBTOOL
65 (Look at the libtool info page about versioning for guidelines)
66 (if MAJOR/MINOR version has changed, however, you can reset all to 0)
67 - FIXME: autotools have latest config.{guess,sub}
68 This is needed in order to support newer platforms.
69 On Debian install the autotools-dev package to get these.
70 Someone please add some more useful info here on how to do this
71 - while (IS_PRERELEASE)
73 - increase the nano number (starting with 2)
74 - check out a fresh anonymous copy
75 cvs -d:pserver:anonymous@cvs.gstreamer.sf.net:/cvsroot/gstreamer \
76 co -rBRANCH-RELEASE-0_3_3 gstreamer
77 - make distcheck, rpm build should pass, from a FRESH cvs tree
78 - media tests should be done
79 - source tarball should be installed and tested
80 - rpms should be installed and tested
81 - .2 tarball should be submitted to translation project
82 - put up tarball for a day
88 When we're satisfied with the prereleases, it's time to make the final tarball.
89 It's very important that the tarball we put out is fully checked, works as
90 planned, and generally is generated only ONCE by someone with a relatively
91 clean (and reference) system. We don't want to put out more than one tarball
95 - give the latest prerelease another good testing
96 - proofread the release notes
97 - run bugzilla with the correct module and milestone and include
98 the output in the release notes
99 bin/bugzilla gstreamer 0.7.5 >> src/htdocs/releases/gstreamer/0.7.5.xml
101 - copy www/htdocs/releases/$(module)/$(version) to RELEASE
102 - copy the list of changes, bugs fixed, and API changes and add them to NEWS
103 - update the ChangeLog to account for NEWS, RELEASE, and configure.ac,
104 mentioning the release name
105 - add === release (version) === to ChangeLog
106 - update web site docs
107 - release-specific docs should go in CVS
108 - change docs/current symlink
109 - remove the nano version number in configure.ac, AS_VERSION
112 for example for 0.6.3 :
113 cvs tag RELEASE-0_6_3
114 - run "make release", build rpms
115 - install on gnome's ftp
116 - for plugins docs: run "make update" in docs/plugins to update version info
117 - for docs: run "make upload" from gstreamer/docs to get the new docs online
118 - change www/src/htdocs/entities.gst with the new version numbers
119 - change www/src/htdocs/bugs/bugs.xml and add a new milestone
120 - possibly add new version and milestone to bugzilla
121 - add a news item to the news.xml
125 Time to bring the new version under the eyes of the public.
128 - FIXME: should we md5 the tarballs?
129 - upload to sourceforge
130 upload.sourceforge.net/incoming
131 administer the release
133 - FIXME: announcements
134 - gstreamer-{devel, announce} : a simple mail with RELEASE
136 - linux-audio-dev (if it's a big release) : a simple mail with RELEASE
138 - lwn (if it's a big release)
139 - send mail for translators with URL to .tar.bz2:
140 translation@iro.umontreal.ca
141 - Kick back, have a party, enjoy people coming in on IRC telling us how
143 - Later on, if necessary, merge back latest release branch to current dev
144 branch (if patches to source were made)
148 * get a diff between the branch root and the final release:
149 cvs diff -r BRANCH-RELEASE-0_7_5-ROOT -r RELEASE-0_7_5 > patch
150 * fix up this patch (remove RELEASE)
151 * and apply it to the HEAD branch
152 * update nano version to 1 in configure.ac
155 * change to a HEAD branch, make sure it's updated
156 * cvs diff -R -r RELEASE-0_3_4-30SECONDFRENCHMAN
157 gives a list of differences between head and release tag,
158 stuff with > is how it's in HEAD, < is in the rel branch
160 * cvs update -j BRANCH-RELEASE-0_3_4
161 merges the difference made in that branch to the current source
162 this is what you want to use when merging back the branch
163 resolve conflicts and commit
165 Some various random comments that might or might not make sense :
168 * autoconf feature to allow building outside source dir
170 - Package version policy
171 - Use major.minor.micro versioning
172 - Before 1.0.0, Update micro until code and API are fairly stable,
175 Update major when code and api hit new level of stability or major features.
176 Update minor on API changes.
177 Update micro on API-compatible changes.