3 ms·

I'm not a GTK developer so please spare me the shooting of the messenger. All I did was read their documentation. From what I've seen there are very few paid de

I'm not a GTK developer so please spare me the shooting of the messenger. All I did was read their documentation. From what I've seen there are very few paid developers actually working on GTK. Everyone else is volunteers and none of them are interested in maintaining deprecated APIs for any protracted amount of time. Even with the removal of a lot of deprecated functions in GTK 4, there is still a ton of untested code sitting around that nobody really maintains. You're welcome to write tests for these and maintain an external compatibility layer yourself if you want, but it makes no sense to expect other volunteer developers to do this for you when the old versions are considered stable.

rleigh 6y ago
> "Everyone else is volunteers and none of them are interested in maintaining deprecated APIs" This is a complete cop-out. It's maintained by several RedHat employees as part of their duties, and a handful of volunteers. Every software project on the planet, including commercial ones, is maintained with limited resources. The amount of development and maintenance which is possible is constrained by the available developer hours, and work is budgeted based on that. The cost/benefit of maintaining the compatibility code is so low that it's not even worth the effort to remove it. The time taken to drop it was likely on a par with the time to retain it. It was already written. But the cost imposed on all their userbase after removing it is absolutely huge. And it means that an application can't target old and new versions due to the break. That wreaks havoc with support lifetimes and imposes thousands of developer-hours of effort for porting. Lots of effort... just to get back to where you were. Unjustifiable. I could understand if there was a huge benefit to be gained. But there isn't. And when you look at what they do spend their time on, so much is wasted on other activities that justifying its removal based upon developer resources wears a little thin. It's a weak justification which ultimately boils down to just wanting to, and completely ignoring the actual users of the library.
- cycloptic 6y ago
  If the cost/benefit is so low then you do it. I'm completely 100% serious about this, I assume you have some customers lined up who are willing to pay for this so just take the money and don't worry about what anyone else does. Make it as an external library so you don't have to spend time convincing upstream to merge and maintain it. None of the existing volunteers are willing to do this work, and the paid developers get paid to work on what Red Hat customers pay them to work on, which evidently is not related to maintaining legacy applications at all. If they want to leave money on the table, that's their problem. There is nothing wrong about what you're saying but it's mostly hot air, you're preaching to the choir here.
deleted 6y ago
[deleted]

rleigh 6y ago

> "Everyone else is volunteers and none of them are interested in maintaining deprecated APIs" This is a complete cop-out. It's maintained by several RedHat employees as part of their duties, and a handful of volunteers. Every software project on the planet, including commercial ones, is maintained with limited resources. The amount of development and maintenance which is possible is constrained by the available developer hours, and work is budgeted based on that. The cost/benefit of maintaining the compatibility code is so low that it's not even worth the effort to remove it. The time taken to drop it was likely on a par with the time to retain it. It was already written. But the cost imposed on all their userbase after removing it is absolutely huge. And it means that an application can't target old and new versions due to the break. That wreaks havoc with support lifetimes and imposes thousands of developer-hours of effort for porting. Lots of effort... just to get back to where you were. Unjustifiable. I could understand if there was a huge benefit to be gained. But there isn't. And when you look at what they do spend their time on, so much is wasted on other activities that justifying its removal based upon developer resources wears a little thin. It's a weak justification which ultimately boils down to just wanting to, and completely ignoring the actual users of the library.

cycloptic 6y ago
If the cost/benefit is so low then you do it. I'm completely 100% serious about this, I assume you have some customers lined up who are willing to pay for this so just take the money and don't worry about what anyone else does. Make it as an external library so you don't have to spend time convincing upstream to merge and maintain it. None of the existing volunteers are willing to do this work, and the paid developers get paid to work on what Red Hat customers pay them to work on, which evidently is not related to maintaining legacy applications at all. If they want to leave money on the table, that's their problem. There is nothing wrong about what you're saying but it's mostly hot air, you're preaching to the choir here.

deleted 6y ago

[deleted]