* Create Business Template and override TemplateTool_checkUpgradeConsistency script to set the Business Template list related to your project
* Set extremely high business_template_skin_layer_priority (like 10000.0)
* Create Business Template and override Base_getUpgradeBusinessTemplateList script to return the Business Template list related to your project
* Make sure the priority of this skin folder in skin selection is above erp5_upgrader. A value of 60 for business_template_skin_layer_priority is recommended.
* Develop constraints and set Constraint Type following upgrader steps
* To upgrade site install first XXX_erp5_upgrader, then erp5_upgrader
* To upgrade site install first your custome upgrader business template, then erp5_upgrader
* Solve the alarm portal_alarms/upgrader_launch_full_upgrade
The erp5_upgrader business template tries to upgrade ERP5 to the latest version (ie. SVN HEAD) whatever the version which is currently installed. It uses introspection to decide what should be upgraded (or not) and how. It is based on an alarm design which makes sure that everything on a given ERP5 site satisfies certain criteria: version of system libraries, version of products, version of business templates, existence of certain tools, configuration of certain tools, etc. If all alarms are in OK state, it is considered as a proof that the upgrade process went well from an instance maintenance point of view (but it does not prove that the upgrade process produces working instances).
erp5_upgrader is tested on a given set of instances in various releases (ex. 5.4.2, 5.4.3). Once all tests pass, it can be released, together with the rest of other business templates. The release process of erp5_upgrader includes a minimal patch of the XML which replaces the HEAD upgrade by appropriate release number.
\ No newline at end of file
erp5_upgrader business template upgrades ERP5 to the latest version from whatever the version which is currently installed.
It uses introspection to decide what should be upgraded (or not) and how. It is based on an alarm design which makes sure that everything on a given ERP5 site satisfies certain criteria: version of system libraries, version of products, version of business templates, existence of certain tools, configuration of certain tools, etc.
If all alarms are in OK state, it is considered as a proof that the upgrade process went well from an instance maintenance point of view (but it does not prove that the upgrade process produces working instances).
