Template:TemplateProcessOfDevelopmentBySubContract - Revision history

Eldy at 12:28, 19 February 2021

2021-02-19T12:28:41Z

← Older revision		Revision as of 12:28, 19 February 2021
Line 9:		Line 9:
	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.		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.		All other [[Language_and_development_rules\|development rules]] must be applied. If not, the PR will not be refused and if development of module were subcontracted, delivery will be refused and payment may not be done.

Eldy at 12:27, 19 February 2021

2021-02-19T12:27:24Z

← Older revision		Revision as of 12:27, 19 February 2021
Line 2:		Line 2:

	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:		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.		* 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, ...)		* 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.		* 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.		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.		* 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.		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.		All other [[Language_and_development_rules\|development rules]] must be applied.

Eldy at 12:27, 19 February 2021

2021-02-19T12:27:05Z

← Older revision		Revision as of 12:27, 19 February 2021
Line 9:		Line 9:
	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.		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.		All other [[Language_and_development_rules\|development rules]] must be applied.

Eldy at 12:26, 19 February 2021

2021-02-19T12:26:52Z

← Older revision		Revision as of 12:26, 19 February 2021
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 ~~manage~~ the new ~~role usage_organize_event on projects)~~.		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.

Eldy at 12:09, 19 February 2021

2021-02-19T12:09:36Z

← Older revision		Revision as of 12:09, 19 February 2021
Line 1:		Line 1:
	Module and new managed objects must be generated with ~~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 manage the new role usage_organize_event on projects).		Goal is to have module included in core so modification of core files is possible (for example to manage the new role usage_organize_event on projects).

Eldy: Created page with "Module and new managed objects must be generated with modulebuilder. Goal is to have module included in core so modification of core files is possible (for example to manage..."

2021-02-19T11:57:58Z

Created page with "Module and new managed objects must be generated with modulebuilder. Goal is to have module included in core so modification of core files is possible (for example to manage..."

New page

Module and new managed objects must be generated with modulebuilder.

Goal is to have module included in core so modification of core files is possible (for example to manage the new role usage_organize_event on projects).