Re: First deprecate APIs and then remove them in the next major version

[Christian Schoenebeck <schoenebeck linuxsampler org>]

On Samstag, 16. Dezember 2017 14:17:11 CET Matthias Clasen wrote:
> > I mean to me it looks like nobody even considered in the past to keep old
> > APIs
> > at all. Currently it is just a common rule "ok, we are now on the next
> > major
> > version branch, we are now safe to do whatever we want to do, so let's
> > start
> > removing everything we don't like anymore".
>
> Maybe give a concrete example of an api that we could have 'preserved with
> no effort"
> and yet removed out of folly ? I would be interested.

Of course I can give you examples. But I wonder if it makes sense to continue 
the discussion. From the responses I see here it looks pretty clear to me what 
the next answers will be.

But since you asked for it, here are some of the things that immediately come 
to my mind which should not have been dropped in my opinion:

        * UI manager
        * stock IDs
        * gtk actions

but also some individual common short hand functions like 
gtk_widget_modify_bg() for instance.

> To me this reads like a misunderstanding.

I am aware about the release cycles and their implied procedures of gtk and 
co, really. I can't remember if we already used gtk 1, but it was definitely 
since gtk 2 that we were using it as GUI framework and are maintining our code 
base since then up to including the latest gtk 4 development branch.

> Moving an application from GTK3 to GTK4 means porting work. But you do it
> only once,
> and you don't retain GTK3 compatibility. At least, that is not what the
> GTK+ team
> recommends you should do.

What I tried to explain is that what you and other people here see as "normal" 
release cycle procedures for gtk, is no longer a normal procedure for any 
other major application level framework out there nowadays. For most of 
today's application developers, API stability is *the* most important criteria 
to pick a framework solution, far more important than its feature set.

Just one example: if you have an application on top of Qt, the last major 
porting work you had to do was from Qt3 to Qt4. That was more than 12 years 
ago. From Qt4 to Qt5 there were almost no API break at all, so little apps 
just had to (more or less) recompile for Qt 5, and bigger apps only required a 
very limited amount of effort to port them to Qt 5. As a consequence even huge 
Qt application projects are still following the latest Qt major version today, 
which is hardly feasible for large gtk apps from an economical point of view.

The API breaks of native frameworks on Mac and Windows are even less in that 
time range. Chances are that even your compiled binaries from back then would 
run today.

> If you want to stick with GTK3, you are more than welcome to do so for
> years to come.

Of course, and they stop there.

As a consequence the popularity of gtk shrinks, there are less contributions, 
and so on.

On Montag, 18. Dezember 2017 00:16:34 CET Emmanuele Bassi wrote: 
> It would be *great* if we could review all incoming patches; sadly, we
> either do that, or we spend time actually developing the toolkit.
>
> Plus, if you have a patch lying in bugzilla for *13* years and you
> never bothered to actually poke people about it, then I don't think
> it'll ever get bumped up in terms of priority on the list of things to
> do.
[snip]
> Your role doesn't terminate at sending a patch.
>
> It's your bug, your patch, and your responsibility for bringing it up
> to the people *volunteering* to work on GTK. If you have a patch that
> is languishing in Bugzilla, join the #gtk+ IRC channel on
> irc.gnome.org, or send an email to gtk-devel-list.

Usually maintainers decide which issues are major ones, and which ones are 
getting priority. That's not the job of the reporter.

Many of the most talented developers and engineers I know are very humble/shy 
and would immediately give up on that since they avoid annoying people.

Obviously with open source projects the common rules are a bit different than 
with proprietary, pure commercial ones. But even with open source projects 
there is usually a differentiation between somebody who just files a bug 
report, and somebody who actually also comes up with a patch to fix that issue.

But to be fair, I wonder if not even the usage of Bugzilla is one of the 
reasons why the management of patch submissions is currently going wrong with 
gtk. I mean Bugzilla is known for its potential to simply create a huge black 
hole.

Fact is, due to the way patches are currently handled for gtk; you send a 
couple patches and then you give up.

CU
Christian