| 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, ...) |
| - thaytan or thomasvs get tired of being lazy. |
| |
| 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. |
| |
| RELEASE PROCEDURE: |
| ----------------- |
| |
| - www/bin/new-release is a release helper script. It automates a lot of the |
| tedious work. Now releasing looks like this: |
| |
| - before release: |
| - make sure all blocker bugs for that release are fixed or deferred |
| - make sure you have a local copy of all online files |
| - 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) |
| - Make one or more prereleases |
| - Make sure you've got the latest clean CVS of the module |
| - Run bin/data-get in www/ to sync data from website |
| - Bump the nano number to > 2 (eg, first pre-release for |
| 0.10.12 is 0.10.11.2) |
| - Re-autogen if not in maintainer-mode (which you should be) |
| - run 'make release' to build the tarballs |
| - copy tarballs+md5 sums to the data/src/$module/pre/ dir |
| - Run bin/data-put in www/ to sync the new tarballs to the website |
| - Announce the availability of the new tarballs |
| - Tell the translation project by sending an email to |
| coordinator@translationproject.org, eg: |
| Subject: gst-plugins-bad-0.10.5.2.pot available |
| Tarball is at http://gstreamer.freedesktop.org/src/gst-plugins-bad/pre/gst-plugins-bad-0.10.5.2.tar.bz2 |
| FIXME: Not sure if the translation project bot parses version strings |
| with a nano correctly. |
| |
| - bin/new-release (module) (version) (checkoutdir) (release name) |
| - updates cvs |
| - allows you to update versioning in configure.ac |
| - rebuilds |
| - updates ChangeLog |
| - adds a new releases/module/version.xml file and lets you edit |
| --> here you add/fix up the features (from ChangeLog) and check |
| contributors |
| - allows you to update NEWS file with snippets from RELEASE |
| --> copy stuff |
| - rebuilds docs for plugins |
| - rolls release tarballs and puts them in the local www/data tree |
| - uploads docs to website |
| - commits changes to po files |
| - shows you a diff for evaluation |
| |
| - build packages to test |
| |
| - release: |
| - Update the doap file to insert the new release info |
| - cvs commit in the tree |
| - tag tree |
| for example for 0.6.3 : |
| cvs tag 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 |
| - add entry on website |
| + Edit src/htdocs/news/news.xml and add a new item at the bottom. |
| - commit additions to website |
| - add versions and milestones in bugzilla |
| - upload new tarballs to gnome ftp |
| + e.g: |
| scp gstreamer-0.10.42.tar.gz master.gnome.org: |
| ssh master.gnome.org |
| install-module gstreamer-0.10.42.tar.gz |
| |
| - Send release announcements to: |
| 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 |
| |
| |
| |
| |
| |
