I'm all for this proposal, however I'm very concerned that we're still drowning in technical debt from the last similar migration (ContentHandler), and if we go ahead with this without first cleaning up our technical debt we're going to be stuck supporting three different systems, two of which are legacy and deprecated.
So I have a tough time supporting working on this proposal without first finishing the previous migration and getting rid of that technical debt.
Cleaning up tech debt first is always good advice. I'm aware that there are still some loose ends left from the ContentHandler migration, but I did not the impression that it's overwhelming. In any case, I'd be happy to work on this if I have someone to look at patches in a timely manner. Shall we do that together? Can you give me a list of tickets?
One point I don't follow is the bit about supporting three systems. ContentHandler isn't going to be deprecated, quite the contrary. Do you mean we need to support different db schemas? I agree that this is a concern.
Ah, I suppose the tracking ticket is Phab:T145728. There is quite a few subtasks, but it doesn't look so horrible. A handful of extensions are still using deprecated functions. I'm happy to help sort this out. The main issue seems to be manually testing these extensions if they don't have sufficient unit tests (or none at all).
When we introduced ContentHandler, we decided to not let the deprecated methods issue deprecation warnings at runtime, leaving that for "later". As such things go, "later" never happens until something breaks. I suggest we are a bit more aggressive about deprecating interfaces in the future.
