[gst-devel] gearing up for 0.4.0

[Thomas Vander Stichele]

Hi team,

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
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

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.

*** 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

*** TESTING

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
stuff ;)

Thomas

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/