30,997
edits
Language and development rules: Difference between revisions
Jump to navigation
Jump to search
m
→Rules to define branch target of a contribution
Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 629: | Line 629: | ||
The rules to decide if a contribution (Pull Request) must be pushed into an old maintenance branch or into development are not strict and are often defined by the good sense (pragmastism first). | The rules to decide if a contribution (Pull Request) must be pushed into an old maintenance branch or into development are not strict and are often defined by the good sense (pragmastism first). | ||
We can find help on the graph found on this page [[:Category:RoadMap#Merging_PR_process_.28develop_or_maintenance_.3F.29]] | We can find help on the graph found on this page [[:Category:RoadMap#Merging_PR_process_.28develop_or_maintenance_.3F.29]] | ||
=About composer= | |||
Composer is a tool to make deployment of PHP packages. Dolibarr is an application that use dependencies that are PHP packages so we could imaging to use composer to install Dolibarr. | |||
This is not a good idea as it is just technically not possible for the following reason: | |||
* First, you must understand that composer is a tool '''to deploy a frozen image of a package''' (like is Docker). It is a tool to '''deploy''', not a tool to '''manage dependencies''': Dolibarr is an application that has a lot of dependencies, but for each of them, the Dolibarr project has to apply some patches to have the dependencies working correclty (for diferent reasons, see the file dev/dolibarr_changes.txt for full list). Each PHP dependency has at least one change to do to have it working correctly. So the image of a library L that Dolibarr needs is NOT the image provided into the composer package by the L project. | |||
After discussion with the author of the composer package, it appears that if a large project needs to use composer, the good way to do is to build ourself a very large package called "dolibarr" with no composer dependencies and all external libraries embed into the same composer project. The dependency system of composer project was simply designed to use an exact version of a library and not to use a patched version of this library. | |||
* Second point is again a problem with the composer dependencies system: Each dependency on a library has itself a high number of dependency. | |||
* Third point is also problems with the dependency system: When you install an external library this library has dependency and each of this depency of depencies are constraints with each other and with PHP version. Library L1 is compatible with PHP x to x+n and library L2 is compatiblewith PHP y to y+m, etc... To have an application working correctly, you must find a PHP version that will be common to all the expected packages. But when you are using a large number of high level of libraries, it with you are depending on a very large number of low level of libraries (each high level libraries has a lotf of low level libraries as dependencies). And when this number is very large, the number of dependency is so large that your reach a situation where the number of common PHP versions is very low and even does not exists. But Dolibarr must works for every body for a long term, not just on one or two given version of PHP. | |||
* Last point is about security: | |||