Point-to-point version upgrade scripts should be kept in master and backported through applicable releases

[Dan Scott]

Our current approach to version upgrade scripts is a little bit haphazard; some scripts start developing in a release branch like rel_2_1, others get created only in the "tag" branch for a given release, and it can be quite confusing both for packagers and for sysadmins trying to update their system.

For example, if we find a problem in the original 1.6.1-2.0 upgrade script and we've already released versions 2.0.0, 2.0.1, and 2.0.2, it seems reasonable to fix the 2.0-2.1 upgrade script so that someone downloading the 2.0.3 tarball won't run through a known bug. Right now, the person doing the packaging would have to copy the upgrade script from the "tag" branch for 2.0.0, apply the fix, and theoretically commit that copy to the 2.0.3 "tag" branch when that happens. In addition, the packager has to comb through the previous "tag" branches to find the canonical upgrade scripts for 2.0.0-2.0.1 and 2.0.1-2.0.2 to put in the tarball.

Similarly, a sysadmin who wants to upgrade from 2.0.3 to 2.2.0 will likely have to download the latest 2.0.x tarball as well as the latest 2.1.x tarball and the 2.2.0 tarball to pull all of the relevant scripts from each of those tarballs (as we currently don't package the complete set of upgrade scripts in each tarball - although sometimes stubs make their way in).

Proposal:

1) Create a new directory, Open-ILS/src/sql/Pg/version-upgrade, intended to hold all of the canonical version upgrade scripts
2) Put all of the canonical version upgrade scripts into the new directory in master so they can be maintained in one spot
3) Backport the version-upgrade directory to at least rel_2_2, and arguably to rel_2_1 while it's still relatively young
4) From that point on, fixes can go directly into the canonical upgrade scripts in master and get backported appropriately

Benefits:
  * Packaging simplicity: the packager simply takes a cut of the latest version of the code, no special steps required to hunt down the right versions of each script
  * Upgrade simplicity: a sysadmin can simply download the latest tarball (or checkout master) and apply all of the point-to-point version upgrade scripts to get current
  * Less directory pollution: moving the scripts out of the Pg directory into their own subdirectory will cut down on the number of files in the top-level Pg dir

[Dan Scott (denials)]

Pushed user/dbs/lp894052-version-upgrade to working repo; covers all upgrade scripts, starting from 1.6.1->2.0 through 2.2-alpha1.

Also renamed the scripts that were inconsistently named.

Note that the 2.0.* point-to-point scripts could stand to have some extra scrutiny.

[Mike Rylander (mrylander)]

Looks like a good step in the right direction. Merged to master.

Note: I got one merge conflict in Open-ILS/src/sql/Pg/version-upgrade/2.0-2.1-upgrade-db.sql, silenced with -X theirs:

<<<<<<< HEAD
UPDATE asset.call_number SET id = id WHERE deleted IS FALSE OR deleted = FALSE;
=======
>>>>>>> eg-working/user/dbs/lp894052-version-upgrade

[Dan Scott (denials)]

Thanks Mike. I think your merge conflict went the wrong way though, as that seems to have undone LP 893683 "Upgrades from 2.0 to 2.1 update deleted call numbers" (commit 512400e63a3cb5362545b7ca0cc9729ac628774a in master)?

[Dan Scott (denials)]

I've pushed user/dbs/lp893683_redux in the working repo to restore the "WHERE deleted..." version of the UPDATE statement, should you care to push it...

[Mike Rylander (mrylander)]

Sorry for the backwards conflict resolution. Your update is now merged to fix that.