Re: New rule

[Matthias Clasen <matthias clasen gmail com>]

On Thu, Oct 21, 2010 at 8:54 PM, Owen Taylor

>  - Making sure there is information out about how to fix applications
>   that need to be fixed. If updating the porting guide is too hard
>   to do immediately, or you are changing something that was never
>   in GTK+ 2, then send mail to desktop-devel-list describing the
>   change and what it takes to deal with it.
>
>  - Considering how your changes fit in with the release schedule. If
>   GNOME 2.91 is going out on Monday, don't land a breaking ABI on
>   Friday.
>
>  - If your change is going to cause major breakage, figuring out
>   in advance what's going to break and work with maintainers to make
>   sure that there are fixes ready to go in immediately.
>
> (And, yes, people have often been doing these things.)
>

Here is what I have done:

1. Introduce new GtkComboBoxText api in 2.91.1

2. Backport new GtkComboBoxText api in 2.23.0

3. Deprecate GtkComboBoxEntry and combo box text convenience api in
both 2.23.0 and 2.91.1

4. Write patches to port some 30 modules to the new apis and file them
all in bugzilla

5. Remove the deprecated api in git master


Now, this was certainly done very quickly, and not widely announced.
But I don't accept the notion that I haven't tried hard to avoid a)
breaking 2.91.1 with this change and b) make it as easy as possible
for people to keep things working after 2.91.1.