[gst-devel] [gst-cvs] tpm gstreamer: gstreamer/ gstreamer/docs/gst/ gstreamer/gst/ gstreamer/tests/check/gst/

[Tim Müller]

On Wed, 2008-01-16 at 23:32 +0200, Stefan Kost wrote:

> any ideas how to handle such changes a bit more graceful. The issue:
> I build my app against gst-cvs and use disable-deprecated. So if there is such a
> change my build fails. So far okay. Old API deprecated, new api there as a
> replacement - available since 0.10.16. Okay, check for gst-0.10.16 and use new
> api if we have it. Bang. There is no 0.10.16 available (yet).

Why not just check for 0.10.15.1 and use the new API, and if someone
complains about it not building, tell them to cvs update core? Just like
we do for the plugins modules basically. If you build against CVS and
use disable-deprecated you'll have to live with the consequences, I
don't think it's really worth working around that.


> Should we only activate the deprecations after bumping the version? How do
> others handle that? reconfigure all the build-slaves and developer checkouts
> (remove the disable deprecated). Do I overlook something obvious?

You could just add an #undef GST_DISABLE_DEPRECATED before the first
include in the affected source file(s) if you don't want to change over
to the new API quite yet.

 Cheers
  -Tim