Closed totten closed 8 months ago
I believe the issue became moot when CiviRules made a major-version branch. (A maintenance branch for <5.37 with older civix templates; another branch for >5.38 with newer civix templates.) If someone wants to purse, then... I guess comment+reopen...
(This is an off-shoot from discussion with @jaapjansma in https://lab.civicrm.org/extensions/civirules/-/merge_requests/221.)
Definition
The "Database Upgrader Class" (
civix generate:upgrader
) is a mechanism for managing schema changes on behalf of an extension. One defines a class similar to this (pseudocode):Mechanism (General)
This mechanism relies on two major pieces:
The approach has evolved:
main.php
andmain.civix.php
- each file had stubs forhook_install
,hook_enable
, etc)<upgrader>CRM_Myext_Upgrader</upgrader>
. Civix doesn't need to provide 2x6 stubs -- it merely sets one XML tag.(Aside: Neither of these approaches use "mixins". The goal is similar -- reduce boilerplate. But the APIs+mechanics are different.)
Mechanism (Civix changes)
As of v22.12.1, civix made a full switch from heavy upgrade-classes (<=5.37) to light upgrade-classes (>=5.38). It warns before doing so, but it doesn't provide any alternatives.
<compatibility>
flag. (If the target version was <=5.37, then it would use the original/heavy way.) However, QA was difficult. To do it right, one should alternately raise/lower/raise the<compatibility>
flag. After each transition, ensure that several pieces look correct -- and then run the full lifecycle (install=>upgrade=>disable=>re-enable=>uninstall=>etc)... and do that on multiple versions of CiviCRM. Which is a lot QA work. And so there were various bugs. And this wasn't officially released.Alternatives
Personally, if I needed to use current civix to make a database-upgrader for on an old CiviCRM, I would consider backporting https://github.com/civicrm/civicrm-core/pull/20091 + https://github.com/civicrm/civicrm-core/pull/20090 + https://github.com/civicrm/civicrm-core/pull/20116 (and possibly 1-2 bugfixes related to cache-management). The upshot is that the old Civi would run newer extensions. I like that
git
logs provide pointers on what to do. But obviously the cost-benefit calculus varies based on specific version#s, #deployments, patch-mgmt tooling, #extensions, etc.Alternatively, if one really needs a more flexible generator... something generate DB-upgraders in either old or new style... then yes, I do think it's possible. After all, we do have working templates for both styles. But I think it sounds easier than it actually is.
<compatibility>
-- does it modify both themain.php
andmain.civix.php
andCRM/Myext/Upgrader.php
? What happens when you lower the<compatibility>
?)I suppose... the smallest adaptation might be something like...
civix upgrade
hits the incremental-upgrade step (22.12.1.up.php
), it asks if you want to convert. But it gives the option to skip conversion.myext.civix.php
to conditionally provide lifecycle-stubs. (If there is anUpgrader
class and ifinfo.xml
does not specify<upgrader>
, then generate stubs forhook_install
,hook_uninstall
, etc.)myext.php
as-is.CRM/Myext/Upgrader/Base.php
as-iscivix upgrade
,civix generate:module .
,civix generate:upgrader
), do a validation check. Show a warning if it looks like the code uses the old style.civix upgrade --start=22.12.0