mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-09-09 05:38:58 +00:00
108 lines
4.6 KiB
Text
108 lines
4.6 KiB
Text
Set of 0.4.0 proposals
|
|
|
|
* module versioning
|
|
- we need an agreement on how we are going to version the separate modules.
|
|
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 against
|
|
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 download
|
|
c) major API breakage needs to be clear; we don't expect really old players
|
|
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 able
|
|
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 pre-release
|
|
tarballs/packages and actual released ones.
|
|
|
|
my idea here would be :
|
|
a) releases are named as normal
|
|
e.g. gstreamer-0.4.0.tar.gz
|
|
gstreamer-0.4.0-1.i386.rpm
|
|
|
|
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 number.
|
|
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 maintainer
|
|
mode, but keep the fourth version number and increase that for each cut.
|
|
So we'd stop developing the module, switch to maintainer mode, up the
|
|
version number to
|
|
gstreamer-0.4.0.2.tar.gz
|
|
and test that.
|
|
|
|
d) when we are happy with the precuts, we drop the fourth number and make
|
|
a release
|
|
|
|
Summary :
|
|
* all "official" released versions have sane versioning with three numbers
|
|
* 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
|
|
|
|
* build code stuff duplicated between various modules
|
|
- how do we integrate these ? this pertains to stuff in autogen.sh,
|
|
duplicate stuff in configure.ac (which should probably be moved out to
|
|
custom .m4 files and yanked in), and maybe testing stuff
|
|
|
|
* what possible ways are there to build 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 need
|
|
the possibilities mapped out once and for all ;) IMO the effort going into
|
|
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 hard
|
|
to allow for more than one variation. The bigger step is from zero to one.
|
|
|
|
so, what are they ?
|
|
- glib1 & gtk1
|
|
- glib1 & gtk1 & libxml
|
|
- glib2 & libxml2
|
|
|
|
* media suite
|
|
- media files on the site should be renamed to simple uniform names
|
|
- and split up based on size
|
|
- described by features/content
|
|
|
|
* when to branch in CVS ?
|
|
|
|
* automatic build testing
|
|
- tinderbox ? useful ?
|
|
- small build scripts
|
|
|
|
* automatic functionality testing
|
|
- an md5sink would be useful to do this
|
|
- something automated is needed; it should check if you have the plugins
|
|
that are needed to test other plugins
|
|
|
|
* media player
|
|
|
|
* packaging
|
|
- dependency libs should be easily available
|
|
|