Your last statement while true, doesn't quite support breaking things even
just "a little".

What made gtk2 stagnant is that we never anticipate a predictable breakage
and assumed gtk2 was going to the only stable release forever among other
things. Developers are okay if they can predict when they are going to need
to update their apps. We could have said (we will break API and release
Gtk3 in 3 years).

So the fact that gtk2 got stagnant doesn't mean that API stability was a
bad thing.

I think we are pissing off Gtk+ users outside of the GNOME project, and if
we keep asking developers to invest time in keeping track of changes for
the code they already wrote they are just going to give up and use
something else to write their apps. Maybe we are okay with this, I feel
uneasy about that.

I've heard you saying "Gtk3 is being a bumpy ride towards 4.0", I am afraid
that if we get used to this "fast and loose" approach, the same thing is
going to be said for 4->5.


2012/11/17 Ryan Lortie <de...@desrt.ca>

> hi Morton,
>
>
> On 12-11-16 03:09 PM, Morten Welinder wrote:
>
>> The breaking of mouse wheel support in gtk+ 3.4 also comes to mind.
>> (Bug 675089 and others, I'm sure.)
>>
>
> If I'm not mistaken, this was a different kind of breakage that we engage
> in a lot of lately: API-incompatible changes on the unstable branch.
>
> As much as those breaks are annoying a lot of people I do believe that we
> gain quite a bit of benefit from playing a little bit 'fast and loose' with
> regards to compatibility.  Our old behaviour of "nothing can change ever"
> led to a substantially stagnated gtk2.
>
> Cheers
>
> ______________________________**_________________
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/**mailman/listinfo/gtk-devel-**list<https://mail.gnome.org/mailman/listinfo/gtk-devel-list>
>



-- 
Cheers,
Alberto Ruiz
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to