428e3ef0a33b7fc98860300a6770bb5df374a14e
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.
5 Release TODO
6 ------------
8 * make distcheck should pass
9 * rpms should build
10 * debs should build
12 Packaging issues will hopefully be less difficult in the future as the build
13 system stabilizes.
15 * after a release, we move in cvs mode and use a .1 nano version number
17 * close to the next release, we make prereleases by upping the nano version
19 * update web site release notes
21 * add release notes to cvs -- why?
23 * test suite should pass
25 * autotools have latest config.{guess,sub}
26 This is needed in order to support newer platforms.
27 On Debian install the autotools-dev package to get these.
29 * depending on how the API has changed update the libtool versioning
30 in configure.ac. Look at the libtool info page about versioning for
31 guidelines.
33 * update package version
35 * roll a preliminary distribution tarball, make sure that it installs fine,
36 registers fine, runs the media tests fine, and uninstalls as well
38 * tag tree
39 http://gstreamer.net/dev/cvs.php
40 add tag to above page
42 * update web site release notes: added to cvs
43 - change the releases/current symbolic link
44 - text version of release announcement can be made from
45 lynx -dump http://gstreamer.net/releases/current/notice.php?clean=1
47 * update web site docs
48 - release-specific docs should go in CVS
49 - change docs/current symlink
51 * update status table cvs status and then click on the release link
52 http://gstreamer.net/admin.php is the portal to all of this
54 * update web site news items for release
55 again, the admin.php page
57 * upload to sourceforge
58 - should we md5 the tarballs?
60 * announce to:
61 freshmeat
62 gstreamer-{devel, announce}
63 linux-audio-dev (if it's a big release)
64 gnome lists (?)
65 lwn (if it's a big release)
68 Should work:
70 * autoconf feature to allow building outside source dir
74 Package version policy
75 ----------------------
77 Use major.minor.micro versioning
79 Before 1.0.0
81 Update micro until code and API are fairly stable, then update minor.
84 After 1.0.0
86 Update major when code and api hit new level of stability or major features.
87 Update minor on API changes.
88 Update micro on API-compatible changes.