Web lists-archives.com

Re: Gtk+4.0




Hi;

On Sunday, 14 August 2016, Chris Vine <chris@xxxxxxxxxxxxxxxxxxxxx> wrote:
On Sun, 14 Aug 2016 21:22:06 +0200
Sébastien Wilmet <swilmet@xxxxxxxxx> wrote:
> On Sun, Aug 14, 2016 at 07:17:34PM +0100, Chris Vine wrote:
> > On Sun, 14 Aug 2016 13:40:55 +0200
> > Sébastien Wilmet <swilmet@xxxxxxxxx> wrote:
> > > When GTK+ breaks the API, it doesn't mean that a higher-level
> > > library needs to break API too. For example, GtkTextView has a
> > > quite stable API, so I think GtkSourceView will still have a
> > > stable API too, to keep backward compatibility during
> > > GtkSourceView 4.
> >
> > However, if your application depends on two GTK-based libraries, the
> > developers for one of which proceed to adopt a development path
> > using unstable GTK versions and one where they stick to stable,
> > surely you are doomed?  Likewise if the two libraries decide to
> > adopt different stable versions (not impossible with a two-year
> > cycle for stable releases).
>
> Yes, that's why it's more important for libraries to follow unstable
> GTK. For apps, it's less important.
>
> GtkSourceView will probably follow unstable GTK, while still trying to
> keep the GtkSourceView 4 API stable.

I was not referring specifically to gnome based libraries.  There are
plenty of others, which will definitely not want to follow the unstable
series.  Even a two year cycle of stable GTK versions will probably be
problematic for them.

It really comes down to the question of what GTK is.  If it is the
GnomeToolKit (or GTK developers are happy for it to become the the
GnomeToolKit) then I can see the merit in the proposal.  Otherwise it
looks to me like a suicide note.

So, let's not beat around the bush: GNOME developers are the vast majority of the GTK contributors, so clearly they get to steer the project the way they see fit. You get to steer the project only if you show up and do the work.

I'm more interested as to why you think this new release policy of an API and feature stable release every two years as a "suicide note" considering that the whole thing has been drawn to cater to non-GNOME consumers of the API after listening to their complaints. GNOME app developers are pretty much used to keep up with bi-yearly releases, whereas non GNOME app developers are often complaining about cycles that are too fast.

If two years are still too fast we can definitely look into making API and feature stable cycles longer; that usually comes at a price of making porting more difficult, but if that is an acceptable cost we can definitely do feature-frozen releases every four years instead.

Ciao,
 Emmanuele.

 
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list