Re: Guidelines for stable branch changes in GLib/Gtk

[Alberto Ruiz <aruiz gnome org>]

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

--
Cheers,
Alberto Ruiz