Manuel Monroy

my point of view as a consumer: notify third-party applications before launching new versions, because in some cases they are mandatory and the purchased products are no longer compatible, which for many like me, we have functions that are not included in the forum and we must buy a plugin to solve it. but we find updates that throw away critical functions and we must indefinitely "patch" something until it is updated, when that update arrives there is already a new one and so the snowball. Therefore, there is a lot of communication between collaborators, I think this has been going on for many years, perhaps one option would be to open a "development team" no longer from third parties but from invision in the market place in such a way that we avoid having prolonged falls in the pages that we manage due to communication problems between you and third-party applications. The only thing that works without fail in these 11 years of IPB despite big changes in versions, are the credit card charges.

Yeah. But if you take a second to think about it, first thing when people are installing their suite will immediately search for those plugins, but when uploading they get errors cuz the plugins are out of date. Thats Why i think this should be added. Anyway, I’m not running Invisioncommunity, I’m not part of the management staff or such. But please speak with your management team and consider adding those. It would be a life savior for all of us!

This is the risk of buying any add-ons. I'm glad IPS checks add-ons before they enter the marketplace. I honestly don't expect more.

Code clean up ✅
Import over FQN ✅
Better use of traits ✅
Search code clean up ✅
Happy PHPStorm without hacks/class_alias ✅
More recent PHP versions needed ✅
Better use of newer PHP functions ✅
More to follow, but I think you’ll be content with the changes to be announced.

constant adoption of new php features and faster bumps in the min. required PHP. PHP is releasing newer versions faster than ever before and killing off the older versions just as fast. the biggest problem i had with IPS 4.x, was that it never really evolved. sure it changed, but it never really embraced features even found in php 5.4, let alone features added thru out 7's life.  Adoption of PSR for your code standards. gonna be honest here, i find your "coding standard" (the formatting of your code) to be the visual equivalent of an angry monkey biting down on a vibrator.  it is a serious amount of unpleasantness to view your code. i think the adoption of PSR, would be more welcoming to third party who has worked out in the wild on other things that use the PSR standard (which most frameworks/libs do now days and by nature a lot of apps have just adopted it from them).  this is a minor one, the embracing of imports+aliases when needed over FQN. FQN can make code look ugly,messy and add a fair amount of bulk. using imports, i can just look at the top of the file and see instantly what it is using. full adoption of semantic versioning. a lot of the problems that you have with 3rd party is cause you guys never stuck with a standard. you would throw in backward breaking changes in patch versions. it is pretty insane that a professional level software company wouldn't use a standard like semantic at the very least. Events Manager. i like the hook system just as much as the next guy, but i think polling of all the apps in the market place to see what is being hooked and how often, and then prioritize event triggers for those, you could probably ease a lot of your woes.  a better form class. i've said it plenty of times over the last several years, i really dislike the form building in 4. i think it was a step in the right direction, but i honestly think it could've been done better. i think it produces an extremely ugly code that could've easily been abstracted better. better use of traits/interfaces/abstract.  there are a lot of times where traits/interfaces/abstract classes should be used in 4.x, and they are simply not. a good example of this is extensions. there have been times where you have updated an extension, where you have removed methods or added in new ones and i had no idea. this is a good place where each extension gets an abstract class, where you can add/remove these methods, so if we don't implement them, they wont blow up.  search. have the search actually use the objects. you currently have things like "titleFromIndexData" and "urlFromIndexData", amongst other methods that attempt (and poorly i might add) to usurp the object class you have given us to do these very things. there are a few of my apps, who do not use the cookie cutter nature you've assigned here, so these methods require addition work from me and at times, impossible to do anything with the provided data, so i have to load the object anyway.  clubs. clubs are sort of a nightmare to implement. cause they are implemented on the item class, but god forbid you use a container/sub container class. then it becomes a huge annoyance to properly implement. clubs should be seriously revisited and much better implemented. i'm sure i have more, but i get the feeling as it is, its already too late in the development of 5.x to serious take into consideration anything i would like to see changed. too bad you guys didn't ask this at more of the start of the development, we might've been able to create something wonderful together :). 

Full in-depth developer documentation with proper real-life full working examples on how to implement framework features.

There have been quite a few developers and theme designers that have left the marketplace or are on the fence as to whether they will continue developing for v4 let alone the v5 platform.
Your team has been working extensively on two different codebases and have become quite intimate with it. 
I would recommend trying to visualize how difficult it would be for a developer new to the platform to setup a development environment and learn how to effectively create programs that meet your marketplace acceptance criteria.
Things to generally think about:
How closely do your programmers adhere to common programming methods for each of the languages you utilize? Is your codebase entirely PHP 8 compliant or are you still utilizing code written for earlier versions?   Are your APIs intuitive to use? Is the cost for entry too high for the first couple of years a developer is learning how to write really good programs and their sales are next to none? Could your error messages be more informative? How does a programmer effectively test their apps?  What lessons learned from your testing team could be useful to a new programmer or to your customers that help beta test two different versions of your suite until such time as v4 is fully deprecated? Would it be beneficial to put a little more structure around public beta testing to minimize the number of additional betas or dot releases after final release. What might you do differently to make becoming a developer more appealing to make recruitment "MUCH" easier and to keep the ones you already have for the long term?

Improvements are nice, but my main concern is maintaining existing projects. I would want to know everything that is not possible anymore and learn if there are alternative ways. This includes hacky solutions like putting a MySQL query in a theme template and things like that. I have lots of customized installations and I don’t want them to be stuck with 4.x.

I will have a look into this for you.
For the time being, if you need any JS, just add this in the theme header or footer options.
I will add this ability in a future version.