Difference between revisions of "Template:TemplateProcessOfDevelopmentBySubContract"
m Tag: 2017 source edit |
m Tag: 2017 source edit |
||
Line 1: | Line 1: | ||
Module and new managed objects must be generated with [[Module ModuleBuilder]]. | Module and new managed objects must be generated with [[Module ModuleBuilder]]. | ||
− | Goal is to have module included in core so modification of core files is possible (for example to | + | Goal is to have module included in core so modification of core files is possible. However, process to submit the work must follow this rule: |
+ | A) Code submission must be done using Pull Request on GitHub. | ||
+ | B) PR content must be the smaller as possible. Each PR must keep the application working the same way as before the merge, when the module is not enabled. For example, you can make one PR for the database addition and migration, and another PR for adding the module descriptor, another one for adding a page, another one for modifying a core file keeping backward compatibility, ...) | ||
+ | C) PR must be atomic (PR must be submitted only once everything seems stable inside 1 PR. | ||
+ | For example, you can't push one PR to make the migration of tables to add a field and another for the script to create the table for a first installation. If you do this, it means there is an inconsistency into the snapshot if we merge only one PR and not the other one. | ||
+ | D) Try to wait that first PR are merged to continue to submit other PR to follow previous rules. | ||
+ | For example: if you add a page that use a new field and want to do it into a different PR to match rule B, wait the previous PR that add that the creation/migration of the new field has been merged. If not, you will break the rule C. | ||
+ | |||
+ | All other [[Language_and_development_rules development rules]] must be applied. |
Revision as of 12:26, 19 February 2021
Module and new managed objects must be generated with Module ModuleBuilder.
Goal is to have module included in core so modification of core files is possible. However, process to submit the work must follow this rule: A) Code submission must be done using Pull Request on GitHub. B) PR content must be the smaller as possible. Each PR must keep the application working the same way as before the merge, when the module is not enabled. For example, you can make one PR for the database addition and migration, and another PR for adding the module descriptor, another one for adding a page, another one for modifying a core file keeping backward compatibility, ...) C) PR must be atomic (PR must be submitted only once everything seems stable inside 1 PR. For example, you can't push one PR to make the migration of tables to add a field and another for the script to create the table for a first installation. If you do this, it means there is an inconsistency into the snapshot if we merge only one PR and not the other one. D) Try to wait that first PR are merged to continue to submit other PR to follow previous rules. For example: if you add a page that use a new field and want to do it into a different PR to match rule B, wait the previous PR that add that the creation/migration of the new field has been merged. If not, you will break the rule C.
All other Language_and_development_rules development rules must be applied.