mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-10-02 16:52:42 +00:00
docs: Update the release script
Remove old cruft from the release script, and change some CVS references to equivalent git commands
This commit is contained in:
parent
8108494a38
commit
72953ec2bb
1 changed files with 2 additions and 177 deletions
|
@ -86,13 +86,11 @@ RELEASE PROCEDURE:
|
||||||
- build packages to test
|
- build packages to test
|
||||||
|
|
||||||
- release:
|
- release:
|
||||||
- cvs commit in the tree
|
- 'git commit -a' in the tree
|
||||||
- tag tree
|
- tag tree
|
||||||
for example for 0.6.3 :
|
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
|
- 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
|
- sync source and packages to website
|
||||||
+ run /bin/data-put in www
|
+ run /bin/data-put in www
|
||||||
- change versions in www/src/htdocs/entities.gst
|
- 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
|
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)
|
- 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
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue