2002-03-08 18:14:15 +00:00
|
|
|
Release should be done on branches from the trunk so that the package version
|
|
|
|
|
in CVS can always be date-generated and core hacking isn't discouraged during
|
|
|
|
|
the release cycle.
|
|
|
|
|
|
|
|
|
|
Note: commands used to make a new branch are as follows:
|
|
|
|
|
(for example, for version 0.3.3)
|
|
|
|
|
|
|
|
|
|
cvs tag BRANCH-RELEASE-0_3_3-ROOT
|
|
|
|
|
cvs tag -b BRANCH-RELEASE-0_3_3
|
|
|
|
|
cvs update -r BRANCH-RELEASE-0_3_3
|
2002-02-02 23:09:20 +00:00
|
|
|
|
2002-01-09 04:50:13 +00:00
|
|
|
Release TODO
|
|
|
|
|
------------
|
|
|
|
|
|
2002-02-02 23:09:20 +00:00
|
|
|
* make distcheck should pass
|
|
|
|
|
* rpms should build
|
|
|
|
|
* debs should build
|
2002-02-02 13:50:03 +00:00
|
|
|
|
2002-02-02 23:09:20 +00:00
|
|
|
Packaging issues will hopefully be less difficult in the future as the build
|
|
|
|
|
system stabilizes.
|
2002-02-02 13:50:03 +00:00
|
|
|
|
2002-02-02 23:09:20 +00:00
|
|
|
* after a release, we move in cvs mode and use a .1 nano version number
|
2002-02-02 13:50:03 +00:00
|
|
|
|
2002-02-02 23:09:20 +00:00
|
|
|
* close to the next release, we make prereleases by upping the nano version
|
2002-02-02 13:50:03 +00:00
|
|
|
|
|
|
|
|
* update web site release notes
|
|
|
|
|
|
2002-02-02 23:09:20 +00:00
|
|
|
* add release notes to cvs -- why?
|
2002-01-09 04:50:13 +00:00
|
|
|
|
2002-02-09 21:05:12 +00:00
|
|
|
* take a FRESH cvs checkout
|
|
|
|
|
|
|
|
|
|
* make distcheck should pass
|
|
|
|
|
|
2002-01-09 04:50:13 +00:00
|
|
|
* test suite should pass
|
|
|
|
|
|
2002-02-09 21:05:12 +00:00
|
|
|
* rpms should build and install
|
|
|
|
|
|
2002-01-09 04:50:13 +00:00
|
|
|
* autotools have latest config.{guess,sub}
|
|
|
|
|
This is needed in order to support newer platforms.
|
|
|
|
|
On Debian install the autotools-dev package to get these.
|
|
|
|
|
|
|
|
|
|
* depending on how the API has changed update the libtool versioning
|
|
|
|
|
in configure.ac. Look at the libtool info page about versioning for
|
|
|
|
|
guidelines.
|
|
|
|
|
|
|
|
|
|
* update package version
|
|
|
|
|
|
2002-02-02 23:09:20 +00:00
|
|
|
* roll a preliminary distribution tarball, make sure that it installs fine,
|
|
|
|
|
registers fine, runs the media tests fine, and uninstalls as well
|
|
|
|
|
|
2002-01-09 04:50:13 +00:00
|
|
|
* tag tree
|
|
|
|
|
http://gstreamer.net/dev/cvs.php
|
|
|
|
|
add tag to above page
|
|
|
|
|
|
2002-02-09 21:05:12 +00:00
|
|
|
* relink current and cvs in the redhat dir and copy the symlinks from the
|
|
|
|
|
current to the new release treee
|
|
|
|
|
|
2002-02-02 23:09:20 +00:00
|
|
|
* update web site release notes: added to cvs
|
|
|
|
|
- change the releases/current symbolic link
|
|
|
|
|
- text version of release announcement can be made from
|
|
|
|
|
lynx -dump http://gstreamer.net/releases/current/notice.php?clean=1
|
|
|
|
|
|
|
|
|
|
* update web site docs
|
|
|
|
|
- release-specific docs should go in CVS
|
|
|
|
|
- change docs/current symlink
|
|
|
|
|
|
|
|
|
|
* update status table cvs status and then click on the release link
|
|
|
|
|
http://gstreamer.net/admin.php is the portal to all of this
|
2002-01-09 04:50:13 +00:00
|
|
|
|
|
|
|
|
* update web site news items for release
|
2002-02-02 23:09:20 +00:00
|
|
|
again, the admin.php page
|
2002-01-09 04:50:13 +00:00
|
|
|
|
|
|
|
|
* upload to sourceforge
|
2002-02-02 23:09:20 +00:00
|
|
|
- should we md5 the tarballs?
|
2002-01-09 04:50:13 +00:00
|
|
|
|
|
|
|
|
* announce to:
|
|
|
|
|
freshmeat
|
|
|
|
|
gstreamer-{devel, announce}
|
2002-02-02 23:09:20 +00:00
|
|
|
linux-audio-dev (if it's a big release)
|
2002-01-09 04:50:13 +00:00
|
|
|
gnome lists (?)
|
|
|
|
|
lwn (if it's a big release)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Should work:
|
|
|
|
|
|
|
|
|
|
* autoconf feature to allow building outside source dir
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Package version policy
|
|
|
|
|
----------------------
|
|
|
|
|
|
|
|
|
|
Use major.minor.micro versioning
|
|
|
|
|
|
|
|
|
|
Before 1.0.0
|
|
|
|
|
|
|
|
|
|
Update micro until code and API are fairly stable, then update minor.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
After 1.0.0
|
|
|
|
|
|
|
|
|
|
Update major when code and api hit new level of stability or major features.
|
|
|
|
|
Update minor on API changes.
|
|
|
|
|
Update micro on API-compatible changes.
|
