From 72953ec2bbd72cc5bdaa5d638f7d3c793074db22 Mon Sep 17 00:00:00 2001 From: Jan Schmidt Date: Mon, 5 Oct 2009 16:41:50 +0100 Subject: docs: Update the release script Remove old cruft from the release script, and change some CVS references to equivalent git commands --- docs/random/release | 179 +--------------------------------------------------- 1 file changed, 2 insertions(+), 177 deletions(-) diff --git a/docs/random/release b/docs/random/release index 473bbcf494..773cb7a2d1 100644 --- a/docs/random/release +++ b/docs/random/release @@ -86,13 +86,11 @@ RELEASE PROCEDURE: - build packages to test - release: - - cvs commit in the tree + - 'git commit -a' in the tree - tag tree for example for 0.6.3 : - cvs tag RELEASE-0_6_3 + git tag -a RELEASE-0.6.3 - bump nano number in configure.ac, commit - - if working in the "stable" release branch, update to this tag to freeze it: - cvs up -r RELEASE-0_6_3 - sync source and packages to website + run /bin/data-put in www - change versions in www/src/htdocs/entities.gst @@ -110,176 +108,3 @@ RELEASE PROCEDURE: gstreamer-devel@lists.sourceforge.net gstreamer-announce@lists.sourceforge.net kde-multimedia@kde.org gnome-multimedia@gnome.org - Update freshmeat with new releases (get Uraeus to do it) -Old release notes - superseded by the www/bin/new-release script. ----------------------------------------------------------------- - -TODO : - - Decide on the next version number (major, minor or micro upgrade ?) - - Get a fresh copy to do the necessary tests on - - If this isn't on the stable branch (like for 0.6), then create a new branch; - - with 0.3.3 as an example, tag is BRANCH-RELEASE-0_3_3 - cvs tag BRANCH-RELEASE-0_3_3-ROOT - cvs tag -b BRANCH-RELEASE-0_3_3 - - update your local copy to the branch: - cvs update -r BRANCH-RELEASE-0_3_3 - - Set the nano to 2 (in configure.ac, AS_VERSION) - - If this is a release candidate for a new major version, override - MAJOR/MINOR in configure.ac - - Do all updates/patches/changes for the release tarball in this branch - - Think of a good codename for the release - - Check the bug lists: - - The idea is to have all bugs for this milestone listed as fixed - - Check all of the bug reports with this version as a milestone, and verify - that these bugs are fixed, or reassign to a later milestone if not - - Check later milestone bugs, and if any of them are fixed, reassign to - this milestone - - Check the list of bugs resolved with milestone HEAD, which should be - assigned to an actual milestone - - create a new $(version).xml file in www/src/htdocs/releases/$(module) - and add that to cvs - - Start updating the release notes on the www cvs tree - - create the base xml file in www/htdocs/releases/$/module)/$(version).xml - - grepping ChangeLog for contributors: - grep "<.*>" ChangeLog | perl -i -p -e 's@\d*-\d*-\d*\s*(.*)\s*<.*$@$1@' | sort | uniq - - use www/bin/bugzilla (module) (version) to get an xml list of the - bugs fixed in this version, and add it to the release .xml - - depending on how the API has changed update the libtool versioning - in configure.ac, AS_LIBTOOL - (Look at the libtool info page about versioning for guidelines) - (if MAJOR/MINOR version has changed, however, you can reset all to 0) - - FIXME: 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. - Someone please add some more useful info here on how to do this - - while (IS_PRERELEASE) - { - - increase the nano number (starting with 2) - - check out a fresh anonymous copy - cvs -d:pserver:anonymous@cvs.gstreamer.sf.net:/cvsroot/gstreamer \ - co -rBRANCH-RELEASE-0_3_3 gstreamer - - make distcheck, rpm build should pass, from a FRESH cvs tree - - media tests should be done - - source tarball should be installed and tested - - rpms should be installed and tested - - .2 tarball should be submitted to translation project - - put up tarball for a day - } - - -Release Period --------------- -When we're satisfied with the prereleases, it's time to make the final tarball. -It's very important that the tarball we put out is fully checked, works as -planned, and generally is generated only ONCE by someone with a relatively -clean (and reference) system. We don't want to put out more than one tarball -with the same name. - -TODO : - - give the latest prerelease another good testing - - proofread the release notes - - run bugzilla with the correct module and milestone and include - the output in the release notes - bin/bugzilla gstreamer 0.7.5 >> src/htdocs/releases/gstreamer/0.7.5.xml - then edit it - - verify all new translations are in and po files are updated: - run 'make download-po' to make sure translations in CVS are up-to-date, - and then 'make update' in po/ (which will update the .pot template too and - merge the changes into the .po files) - - run win32-update from toplevel to copy new versions and enum files - - copy www/htdocs/releases/$(module)/$(version) to RELEASE - - copy the list of changes, bugs fixed, and API changes and add them to NEWS - - update the ChangeLog to account for NEWS, RELEASE, and configure.ac, - mentioning the release name - - add === release (version) === to ChangeLog - - update web site docs - - release-specific docs should go in CVS - - change docs/current symlink - - remove the nano version number in configure.ac, AS_VERSION - - cvs commit - - tag tree - for example for 0.6.3 : - cvs tag RELEASE-0_6_3 - - run "make release", build rpms - - install on gnome's ftp - - for plugins docs: run "make update" in docs/plugins to update version info - - for docs: run "make upload" from gstreamer/docs to get the new docs online - - change www/src/htdocs/entities.gst with the new version numbers - - change www/src/htdocs/bugs/bugs.xml and add a new milestone - - possibly add new version and milestone to bugzilla - - add a news item to the news.xml - -Post-Release Period -------------------- -Time to bring the new version under the eyes of the public. - -TODO : - - FIXME: should we md5 the tarballs? - - upload to sourceforge - upload.sourceforge.net/incoming - administer the release - - - FIXME: announcements - - gstreamer-{devel, announce} : a simple mail with RELEASE - - freshmeat - - linux-audio-dev (if it's a big release) : a simple mail with RELEASE - - gnome lists (?) - - lwn (if it's a big release) - - send mail for translators with URL to .tar.bz2: - translation@iro.umontreal.ca - - Kick back, have a party, enjoy people coming in on IRC telling us how - GStreamer rocks. - - Later on, if necessary, merge back latest release branch to current dev - branch (if patches to source were made) - - TWO WAYS: - A) - * get a diff between the branch root and the final release: - cvs diff -r BRANCH-RELEASE-0_7_5-ROOT -r RELEASE-0_7_5 > patch - * fix up this patch (remove RELEASE) - * and apply it to the HEAD branch - * update nano version to 1 in configure.ac - - B) - * change to a HEAD branch, make sure it's updated - * cvs diff -R -r RELEASE-0_3_4-30SECONDFRENCHMAN - gives a list of differences between head and release tag, - stuff with > is how it's in HEAD, < is in the rel branch - - * cvs update -j BRANCH-RELEASE-0_3_4 - merges the difference made in that branch to the current source - this is what you want to use when merging back the branch - resolve conflicts and commit - -Some various random comments that might or might not make sense : - -- 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. - -NOTES ON STARTING A NEW STABLE SERIES -------------------------------------- -- Given x.y.z being the last devel release, where y is an odd number -- all API/ABI/renaming changes should be done -- for every module: - - get a completely fresh checkout - - set GST_MAJORMINOR to x.(y + 1) - - reset libtool versioning to 0, 0, 0 - - build every piece - - grep for possible non-updates of MAJORMINOR: - grep -r "0\.9" * | grep -v "0\.9\.6" | less -R - change stuff: - perl -i -p -e 's@0\.9(\.[^0-9])@0.10$1@g' (file) changes 0.9. -> 0.10. - perl -i -p -e 's@0\.9([^.])@0.10$1@g' (file) changes 0.9 -> 0.10 - - - - - -- cgit v1.2.3