mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-27 02:30:35 +00:00
176 lines
7.6 KiB
Text
176 lines
7.6 KiB
Text
GStreamer Release Policies (or: why we should become a country and pass laws)
|
|
--------------------------
|
|
|
|
Development Period
|
|
------------------
|
|
Development period is marked by having a fourth (nano) version number of 1.
|
|
During development anything goes short of wiping the tree.
|
|
Just try doing a few basic things :
|
|
- make sure it builds for you !
|
|
- check what you're about to commit with cvs -Q diff -r
|
|
- preferably, keep an anonymous checkout around as well so you can
|
|
immediately update and check if your changes work in a clean tree as well
|
|
|
|
Prerelease Period
|
|
-----------------
|
|
After a bit of development, people want a new release. This generally happens
|
|
when :
|
|
- core developers get anxious to apply massive changes to the core bound
|
|
to break everything
|
|
- a few important plugins decide, as if by magic, to work again (avi, mad, ...)
|
|
- Uraeus and thomasvs get tired of the general laziness
|
|
|
|
Also, this should only be allowed after passing a few sanity checks :
|
|
- make distcheck should pass
|
|
- rpms should build
|
|
- FIXME: should debs be built here ? If so, how ?
|
|
|
|
At this time, we need to do a few prereleases for general checking by all
|
|
interested developers. To minimize the impact on the rest of the core hacking,
|
|
we create a new CVS branch which will go through the pre-releases and finally
|
|
contain the definitive tarball for that version.
|
|
|
|
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
|
|
- 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 core: 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.
|