Dno't know where to put this, so adding to bugzilla then. Just close when the
release notes have been written.

"Some fixes in this release change (fix) behaviour for derived classes of
GstBin. This may cause problems for projects using derived classes of GstBin.
This is *not* a bug. This is a fix for a bug. Projects using workarounds for
this bug may see this hitting back now. That *is* a bug in those projects. This
note is here to help them track the problem.

Documented behaviour:
A GstBin, and any derived class of a GstBin, is defined to have the state of the
contained child with the highest state. Adding new children with a higher state
than the current bin's state, or changing state of children to a state higher
than the current state of the bin, will change the state of the bin itself.
Changing state of a kid or adding a kid with a higher state will do a
non-recursive state-change on the bin (i.e. it changes the state of the bin, but
does not touch other contained children). Likewise, changing state of a bin
non-recursively changes state on the contained children (i.e. the kids do not
notify their parents of the state-change). This non-recursive behaviour is to
prevent recursive (infinite) loops.

The bug:
Non-recursive state changes on the bin after a kid state change (or addition,
which is essentially the same) would force a call to
GstElementClass->change_state(bin) instead of calling the correct virtual
function implementation on the bin. This means that derived classes would not be
notified of the state change. Derived classes requiring work in the state_change
virtual function would not see this work being done when their state changed
because children state changed. This behaviour was fixed.

The problem for derived classes:
Derived classes could work around this problem by keenly keeping track of
children's states and forcing states on children all the time. It needs to be
said that *this is not correct behaviour*, it merely works around this bug.
Likewise, changing state of kids in the change_state handler (or anything called
by that) *is recursive behaviour*. Doing that is fine, but the derived class
either needs to keep track of recursive behaviour and do the right thing, or not
do recursive behaviour at all.

In case of doubt or problems as an effect of these changes, feel free to ask us.
It probably reflects a bug in your application not exposed by the bug in core
until now. We will try to help you fix it."

I just helped Edward (bilboed) fix gnonlin, who was hit by the above. The fix
was easy for me, but not for him. Please add this to the release notes.