[gst-devel] gearing up for 0.4.0
Thomas Vander Stichele
thomas at urgent.rug.ac.be
Tue Jan 29 08:55:07 CET 2002
gearing up for 0.4.0 we probably could do with a few agreements re: the
releasing and stuff. Some of this has been talked about on irc.
I've started a document which I put in cvs to collect my thoughts. I'm
copying a few bits here so we can discuss them and so that I and others
can work on some of these points in order to get them done soon. If not
I feel I'm spinning my thumbs idly ;)
So here are some of the things to consider :
*** POSSIBILITIES IN BUILDING GSTREAMER
I would like to take stock of the combinations of deps possible to build
gstreamer. While most people want only glib2, I think there is merit
in still making glib1 work and willing to put in the effort. I just
the possibilities mapped out once and for all ;) IMO the effort going
making gstreamer build without libxml is the same as making it work with
older glib too. I mean, as soon as you allow variation, it isn't that
to allow for more than one variation. The bigger step is from zero to
so, what are they ?
- glib1 & gtk1
- glib1 & gtk1 & libxml
- glib2 & libxml2
I'm thinking of good ways to set up test builds to test all of the
possibilities here. the autobuild is ok but limited atm.
- we need an agreement on how we are going to version the separate
This needs to meet some requirements :
a) we shouldn't be forced to release all of the modules together
every time (if the plugins have been updated, and still work
a previous core, then only release plugins, for example)
We should start treating the different modules as separate projects
(albeit still closely tied of course)
b) it should be clear for other people what packages they need to
c) major API breakage needs to be clear; we don't expect really old
to keep working with really new cores.
- my idea (which others seemed to agree with) would be to let the micro
numbers run independently. Only when the core API has changed to the
point that other modules are not compatible with them anymore
should we upgrade the minor version.
We can assume/assert that modules with the same minor number will be
to work with each other.
- Example schedule :
* we release 0.4.0 versions of all of the modules
* plugins get updated a few times : 0.4.1 and 0.4.2
* core gets a new scheduler, doesn't affect other modules : 0.4.1
* gst-player gets rapid releases due to arik's recovery: 0.4.1-0.4.5
* core gets a major new update re: events : 0.5.0
* some days later, other modules have been updated to the new core
and the new core starts being useful to other people as well
* release practice
- we should have a simple way to cut releases; something that makes
the necessary adaptions to the source tree
This could also be a simple check list of things that need to pass
- cvs tarballs/packages should be easily distinguishable from
tarballs/packages and actual released ones.
my idea here would be :
a) releases are named as normal
b) as soon as the release is made, we are back in "cvs" mode
i'd use a ".1" for a fourth version number for all cvs versions
so as soon as we release 0.4.0, I'd add a fourth ".1" version
this one would be used during the whole of the cvs period, no
reason to up this manually in between
The packages (rpms in any case, don't know about debs) would still
keep the date as the revision number like they have now, in order
to make it easy to work with snapshots.
c) when we are ready to release this module, I would go back to
mode, but keep the fourth version number and increase that for each
So we'd stop developing the module, switch to maintainer mode, up
version number to
and test that.
d) when we are happy with the precuts, we drop the fourth number and
* all "official" released versions have sane versioning with three
* all "cvs" versions are clearly recognizable by the fourth .1
* all "precuts" are also recognizable
* no tarballs will accidentally spill pretending to be real releases
* upgrading rpm's all through this process is easy
I would like to categorize the currently available media on the site and
rename them/split them up so that I can begin writing automatic testing
suites that tests these media files. Also, for most functionality
tests small video files will do adequately, so they could be split up.
Any thoughts on this ?
Please comment so I can find my way and start implementing some of this
The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
If lovin' you is wrong
then I don't wanna be right
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/
More information about the gstreamer-devel