Am Donnerstag, 21. Mai 2015 09:29:45 UTC+2 schrieb Rob Clayburn:
If you mentor new devs supplying them with the best practices to ensure their code is correct (writing tests, code style etc). The iterative process will produce a positive feedback loop where by devs see the fruits of their labour in a short time, are encourage and enthused by the results and then want to repeat the process, the complete opposite of the current negative feedback loop when you bust a gut for a month on something you personally deem important only to have someone block it based on some arbitrary requirement you weren't even aware existed before you started.
This is also why I'm against say "lets start again from scratch". It reduces confidence in the merit of incrementally contributing to the existing code, and leaves those dev's not capable or willing to work out an entire new architecture watching from the sidelines.
Interfaces first ;) The architecture is mostly defined by it's interfaces. So after the interfaces are settled, there are plenty construction areas where everyone can contribute.
95% of those developers will be coming from the CMS, and that is where their interest lies. When I do a custom project realistically I am not going to use the Joomla framework, I'd sooner work on Express or Laraval, or pick individual composer projects few of which would be those available in the framework. So for me the Joomla Framework is only relevant IF its directly feeding into the CMS. I'd love to see that change and for the framework to become my defacto choice, but it will only ever get there if there are a lot more people contributing to it, and to get those contributors we need to set up a short positive feedback loop in the contribution process.
Another point for "building from scratch". The current CMS libraries were never been written to be used in another application, that's history conditioned. But if we would have the freedom to build a FW and a CMS as an application of that FW, the FW can still evolve while the CMS picks it needs. Of course, there will always be the CMS in the mind. But there's a difference in building a package for the CMS and building a standalone package which also could fit in the CMS.
With regards to Andrew's idea of version'd classes. To my mind there are definitely certain classes which you would not want multiple versions of. JSession, JApplication etc. Basically any class which is required to be initiated before the call stack arrives at a component/plugin entry point should be a known quantity for a 3rd party developer. However MVC etc could have different versions, indeed we already have that in the fact that JModel and JModelLegacy are already in the CMS. I'm currently refactoring Fabrik to use namespaces and the new MCV classes. What I hadn't really appreciated before starting was that it really does allow you to easily swap out class definitions. So you can start with :
Well, if we are particular about that idea, than the only challange would be the application package as it's the crucial point. Of course, i could use two different session packages at the same time, they just have to be separated. Think about a plugin which starts a Session2 on initialisation. The real question is which session is bind to the application. But since total API changes for a session package are very unlike, i think we don't have to worry about it. Just throw in a legacy wrapper before the next major release.