mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-07-02 20:55:55 +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:
Jan Schmidt
parent
8108494a38
commit
72953ec2bb
|
|
@ -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
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue