Thanks @jakabadambalazs2 for bringing up this excellent topic.
I found this thread while searching for Doctrine DBAL and SugarCRM !
The compatibility question is super important.
I have to say that the push to update the architecture of the app and the libraries used by the app is noble and should increase efficiency of development and maintenance substantially.
Updates can, and really should, be done in a way that maintains compatibility with existing 6.5 add-ons.
in fact, it’s possible to support both the Sugar 6.5 API and the Sugar 7.x API.
Did you know, Sugar 7.x uses all of these Symfony components you mention - Doctrine DBAL, Composer, etc. So it doesn’t necessarily break anything to add these to SuiteCRM in a way that is compatible with both Sugar 6.5 and 7.x. Composer doesn’t prevent an add-on module from installing or running using the old Sugar 6.5 API, for example.
The best way to go about this, is to visualize this app as two separate pieces. The Front End, and the Back End.
SuiteCRM can and should be updated to support both Sugar 6.5’s REST v4.1 Back End, and Sugar 7.x’s REST v10 Back End.
From that point, you’re golden. All Sugar 7.x add-ons connect only through the REST v10 Back End, and will work.
As far as the front end goes, this is where most of the undesirable junk is. Repeated code, modified Smarty engine, view code that tries to build SQL queries, etc.
All in favor of creating new front end web user interface, compatible with existing 6.5 and 7.x, using new front end frameworks such as responsive CSS3 and not having any access to do things like build SQL queries, and because it talks only to the REST API, also causes no breakage of compatibility.
In summary, SuiteCRM needs to continue to safely debug 6.5, introduce composer, phpunit, dbunit and other helpful packages, and refactor the underlying poor design of SugarCRM 6.5, all the time maintaining compatibility with modules and the entire SugarCRM 6.5 API, essentialy making the app perfect. It’ll then become more and more easy to see the forest for the trees, get up to 80% test coverage, build a universal responsive mobile/desktop theme and views that are truly pure views and not mucking around deep in the data layer. At this point it becomes simple to add the REST v10 API for total Sugar 7.x compatibility, which allows for the user base to grow and welcome users who rather not be paying the high fees for commercial CRM software.
First however is getting test coverage up. For this, it’s essential to add composer, all the phpunit tests from Sugar 6.5, and activate all of the testing tools used by Sugar 7.x (and pretty much every open source app on github). Jasmine, PHP-cs-checker, PHPCS, there’s a list of about 8 of them I posted on the relevant github issue. These would run tests and allow you to test see whether a change you propose would break compatibility. And then change your code so compatibility is maintained.