Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CRM_Upgrade_Form - Scan CRM/Upgrade/Incremental/any/{VERSION}/* #7421

Closed
wants to merge 3 commits into from

Conversation

totten
Copy link
Member

@totten totten commented Dec 10, 2015

It can be fairly confusing to go back and forth among various PHP and SQL
files to understand upgrade order, and the *.mysql.tpl files have been
excessively prone to merge-conflicts on large upgrade functions.

This PR allows one to define sub-version upgrade steps in separate
files, e.g.

CRM/Upgrade/Incremental/any/4.7.0/100-first.task.php
CRM/Upgrade/Incremental/any/4.7.0/105-second.mysql.tpl
CRM/Upgrade/Incremental/any/4.7.0/200-third.mysql.tpl
CRM/Upgrade/Incremental/any/4.7.0/220-fourth.task.php

The PR does not:

  • Reorganize existing upgrade files.
  • Support pre/post/verify phases (like CRM_Upgrade_Incremental_php_* classes).

@totten
Copy link
Member Author

totten commented Dec 10, 2015

I don't really like the directory name (CRM/Upgrade/Incremental/any/4.7.0/); CRM/Upgrade/v4.7.0/ would seem better. But it's kinda awkward because we still have the separate Incremental/php and Incremental/sql dirs.

@colemanw
Copy link
Member

What about CRM/Upgrade/Steps/4.7.0

@eileenmcnaughton
Copy link
Contributor

I assume we are NOT encouraging people to call them first, second, third file etc... but something like

CRM/Upgrade/Incremental/any/4.7.0/220-CRM-17275.php

OR

CRM/Upgrade/Incremental/any/4.7.0/220-new-financial-type.php

@colemanw
Copy link
Member

Given the goal of making merges easier, a nice structure might be

CRM/Upgrade/4.7/000-add-menu-item.sql.tpl
CRM/Upgrade/4.7/100-modify-options.php

That way if a PR misses the 4.7.1 release date it doesn't matter we can still just merge it in and it will get run during 4.7.2 upgrade. This of course requires the client keeping track of which upgrade steps have run and which haven't, which we aren't (yet) doing.

@totten
Copy link
Member Author

totten commented Dec 11, 2015

@eileenmcnaughton , you correctly interpreted the intent. :)

@colemanw , I've procrastinated a couple days on that approach. We basically have to ditch this PR and write a new one. OTOH, given that the 4.7=>5.0 cycle is going to be long and require some changes to our workflow/PR policies, the increased flexibility on schema-upgrades would be pretty helpful. And I don't want to drag folks through a cleanup/retraining if we're just going to change it again RealSoon.

So... I'll do the alternate PR...

@totten
Copy link
Member Author

totten commented Jan 7, 2016

Closing this one since #7440 is a better design.

@totten totten closed this Jan 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants