docs: Update the release script

Remove old cruft from the release script, and change some CVS
references to equivalent git commands

1 files 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
-
-
-
-
-