Fixed only three months ago ? I’m shocked.
Quite personally, I find the deprecation and obsolescence model of GTK rough to deal with. The maintainers should be more focused on the users of the library and less on their own burden. Every time I recompile an ‘old’ GTK project it seems new a deprecation pops up. What is worse, is that the developers don’t publish a work-around for the deprecation. They seem to just charge ahead leaving an untidy trail of deprecations behind them…
There should be a GTK development rule: for every new deprecation a work around page needs to be published on line.
You have to realise that GTK is maintained by volunteers, and volunteer work is not fungible. You don’t get to tell volunteers to work on what you want.
Well, yes: that’s how deprecations work. Deprecating things doesn’t mean they stop working: it means they are not going to exist in the next major version of the API.
Every deprecation warning has an indication of what should be used as a replacement, and the documentation lists a replacement. For some API there is no replacement, but every major version of GTK has a migration guide.
Of course, if the documentation is unclear, feel free to open an issue and/or a merge request; the API reference links the place where the documentation is defined in the source code, and you can even edit it directly from GitLab.
I’m sorry, but you don’t get to make up rules for projects you don’t contribute to. That’s how this thing called free software works.
Hmm. That’s not how Linus Torvalds makes things work. Easy fix: no documentation, no pull request honored. Keep the poorly documented crap out.
“For some API there is no replacement” – wow, this would break existing code – that’s hostile.
You seem to assume it’s not already the case.
Anyway, this subthread has gone on for too long.
Of course, there are no legal obligations on the side of the GTK-team. But does this mean that there are no obligations at all? If this were true, you would be not volunteers but hobbyists.
Volunteers do it for the good of others, e.g. of the community.
Hobbyists do it just for own sake and own fun (nevertheless, some hobby projects can be useful for others).
Numerous and partially superfluous intentional API breaks indicate that the hobby-hypotesis describes the GTK-development closer to the reality.
It will not break the code (i.e. cause linking errors) unless you do a port and don’t complete it. That is one reason why it is deprecated first and then only removed after a major release.
As probably the most obvious counter-example, Qt periodically deprecates and removes APIs too, and they are a commercial company.
IMO, this topic has run its course.