Change version to 6.0.alpha1

[colemanw]

Overview

It's happening!

[civibot]

🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷

Introduction for new contributors...

• If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
• A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
• A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
• If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
• Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
• A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
• To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
• For more information about contributing, see CONTRIBUTING.md.

Quick links for reviewers...

• ➡️ PR Demo site (can be rebuilt with the command test this please).
• 📖 Review standards
• 🗒️ Review template (brief or verbose)

➡️ Online demo of this PR 🔗

[ufundo]

It's happening!

Jenkins less enthusiastic...

Looks like install crashes quite early:

[Setup:info] [Preboot.civi-setup.php] Load minimal (non-DB) services
[Setup:info] [InstallSchema.civi-setup.php] Install database schema
[Setup:info] [InstallSchema.civi-setup.php] Load basic tables
Error: Call to a member function getHelper() on null in Civi::schemaHelper() (line 339 of /home/homer/buildkit/build/build-4/web/sites/all/modules/civicrm/Civi.php).

Happy to investigate this further unless you are already into it @colemanw ?

[ufundo]

Oh it looks like the 5 in civimix-schema@5 is linked to our core version by this call:

civicrm-core/mixin/lib/pathload.index.php

Line 15 in 726d32a

\pathload()->addSearchItem('civimix-schema', $version, __DIR__ . '/civimix-schema');

If I read it correctly:

• on any 5.x we are registering directory search for [email protected] which is satisfied by the declaration civimix-schema@5 in the file

  civicrm-core/mixin/lib/civimix-schema/pathload.main.php

  Line 4 in 726d32a

  \pathload()->activatePackage('civimix-schema@5', __DIR__, [

  - which then satisfies the demand for civimix-schema@5 in all the extension .civix.php file

So when we bump core up to 6.x we need to either:
a) hardcode the $version in

civicrm-core/mixin/lib/pathload.index.php

Lines 14 to 15 in 726d32a

	$version = \CRM_Utils_System::version() . '.1'; /* Higher priority than contrib copies of same version... */
	\pathload()->addSearchItem('civimix-schema', $version, __DIR__ . '/civimix-schema');

to 5.1
b) bump up all the extensions to use 6 (feels unfeasible with contrib)
c) add search directory for the current version and previous version?

Probably an @totten question!

[totten]

I think my favorite options are:

• Double-register civmix-schema in both 5.x and 6.x sequences, or...
• Just continue with civimix-schema in the 5.x sequence.

In either scenario, the 5.x sequence can be specified formulaically: 6.x = 5.{83+x}. (Example: 6.2 = 5.85.) This ensures that the sequence remains legal without needing us to manually bump numbers.

Since civimix-schema is already "reloadable" (i.e. no hard-conflicts over PHP symbols), it should work the same even if it's loaded multiple times.

My first impulse was to go with the double-registration -- because it preserves the API POV that numbers match core. OTOH, it does create more numbers floating around universe. Keeping the numbers strictly 5.x is systemically tighter (and leaves the window open to introduce 6.x whenever there's an actual BC break).

On my local, I'm able to do basic install either way. Pushing up a commit which shows both.

[colemanw]

@totten it feels like the CiviMix version is unnecessarily tied to the CiviCRM version?
Could they be treated independently? Like how our API version is still 4?

[totten]

@colemanw Yes and no.

• From a 30k ft POV, I like this part of the analogy: we have APIv3 and APIv4, and we could have APIv5. These things coexist regardless of the official CiviCRM version.

  api/v3/                         (the 3.x series)
  Civi/Api4/                      (the 4.x series -- diff contracts; breaking changes)
  

  An analogous play for civimix-schema might be this layout:

  mixin/lib/civimix-schema@5      (the 5.x series)
  mixin/lib/civimix-schema@6      (the 6.x series -- diff contracts; breaking changes)
  

• From a 5k ft POV, I think a better analogy would be ext/recaptcha, ext/search_kit, ext/legacycustomsearches, etc:

  • Each sub-component can track its own independent number. (Each one has a different physical spot where you can set the number.)
  • In fact, the content probably doesn't change much month-to-month.
  • We're so accustomed to "edit+go" that we would likely forget to maintain the numbers without some process-enforcement.
  • There is a conceptual boundary around each folder. You could copy these folders between different builds/versions. (For ext/recaptcha/, we don't really police contracts well enough to encourage that. But for everything under mixin/, it's policed more carefully so that it can be copied around -- and at runtime it uses version_compare() to decide a winner. For version_compare() to be meaningful, you want more decimals. So from a low-level, it's a bit different from APIv3/APIv4.)

[totten]

Yeah, if we're decoupling the version-sequence, then probably the folder-name should indicate the distinctive major-version. This would be more similar to api/v3, Civi\Api4, or mixin/smarty@1.

[ufundo]

for everything under mixin/, it's policed more carefully so that it can be copied around

I think I understand the theory. But in practice, is civimix-schema copied around?

It seems to me that the key requirements are:

• the core version can provide the major version requested in contrib extensions (namely 5)
• successive core versions predominant over older ones (newer is better)

It doesn't make sense that the major version of the mixin is tied to the core major version. If we are slightly stuck with 5 for the major version now, and want to beat all the versions already out there up to 5.82, would switching the core version of civimix-schema to 5.100.[core-version] work?

[colemanw]

But in practice, is civimix-schema copied around?

That's a question Tim & I couldn't agree on when designing Entity-Framework v2. The mixin only needs to get copied into an extension if the author does want to use EFv2, but does not want to bump up their core version requirement to something recent-ish.
I felt that scenario was not worth the trouble of supporting; Tim felt differently and so he went ahead and created this mixin-based system that allows extensions to essentially backport their own copy of EFv2 in the form of civimix-schema.
In practice, has anyone actually used it? I'd guess probably not. However, there's another advantage to the mixin-based approach that Tim designed, which is that if Core ever gets crazy and implements quantum-based entities or something like that and calls it EFv3, extensions can comfortably remain on EFv2 with their own mixins.