From 69ad8b19a1418ef78ac615c8b3eaf63e792d1872 Mon Sep 17 00:00:00 2001 From: Thomas Vander Stichele Date: Tue, 29 Jan 2002 16:41:44 +0000 Subject: [PATCH] first stab at some ideas for 0.4.0 Original commit message from CVS: first stab at some ideas for 0.4.0 --- docs/random/thomasvs/0.4.0 | 108 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 docs/random/thomasvs/0.4.0 diff --git a/docs/random/thomasvs/0.4.0 b/docs/random/thomasvs/0.4.0 new file mode 100644 index 0000000..ddbc777 --- /dev/null +++ b/docs/random/thomasvs/0.4.0 @@ -0,0 +1,108 @@ +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 + -- 2.7.4