2.2-2.3.0 upgrade script is missing updates from minor version update scripts

[Justin Hopkins]

Following an upgrade from tags/rel_2_2_0 to tags/rel_2_3_3 which seemed to go perfectly smoothly I found a problem with the Tpac and a 500 error. Logs shows:

egweb: template error: undef error - Can't call method "maketext" on an undefined value at /usr/local/share/perl/5.10.1/OpenILS/WWW/EGWeb.pm line 81.\n

The source of the problem was a lack of a db function evergreen.get_locale_name() which is added in db update 0723. Update 0723 is included in the 2.2.0-2.2.1 upgrade script but not the general 2.2-2.3.0 script.

I resolved the issue by running the 2.2.0-2.2.1 and 2.2.1-2.2.2 scripts, but generally I think that we should include all 2.2.x updates into the 2.2-2.3.0 script in such a way that if they have already been applied there won't be a problem.

[Mike Rylander (mrylander)]

While we may want to change the policy, what you did in the end -- running through the minor upgrade scripts, then applying the major version upgrade -- is the prescribed upgrade method. At least in the 2.0-ish days, that was well documented in the wiki upgrade instructions.

[Ben Shum (bshum)]

I agree with Mike that previous upgrade instructions in our 2.0 days were more thorough in explaining the necessity of running through every point upgrade along the way up to the next major version.

Perhaps this is something that can be addressed in additional clarification in the existing 2.3 and 2.2 upgrade docs.

[Dan Scott (denials)]

Sorry, no, "the prescribed upgrade method" is a total cop-out. It is _not_ "prescribed" because it is not what is documented. And it smacks of blaming the doc team & to some extent the user for a problem that we--the development team--are responsible for creating in the first place. Especially with 2.2-2.3, which was not even 6 months between releases.

In the old days when it might have been two years between minor releases, and new features went into those releases, and point releases were issued on a random schedule, maybe that policy requiring the user to run every point release update made sense. Although I would still argue no, we mostly lacked an organized policy around how to backport point release updates (those were the heady days before a version_upgrade directory and point-to-point upgrade scripts tended to vary widely between tarballs, with tons of regressions, as we failed to update them in higher release versions).

As "simple" is pretty much always the best policy for users, developers, and documentation writers to follow, I suggest we document a simple policy : any fix applied to a minor release in a patch (e.g. x.y.z - x.y.(z+1) should be contained in the corresponding x.y-x.(y+1) release upgrade script, so that a user can always run the x.y-x.(y+1) upgrade script without having to worry about any of the patch release scripts.

[Dan Scott (denials)]

And here's the simplest possible way of accomplishing this:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/lp1104369_upgrade_all_point_release_scripts

Should be applied to master and backported to rel_2_3. I tested this by creating a clean schema from origin/tags/rel_2_2_0, then running this upgrade script.

However, a big caveat is that only PostgreSQL 9.2 and up offer the "\ir filename" command for including a file from a relative path; so if the 2.2.0-2.3.0 script is not run from within the version-upgrade directory, none of the point release scripts will be found. Which sucks, but it's something we can document rather strongly, and I've added a warning & prompt at the beginning of the upgrade accordingly.

[Lebbeous Fogle-Weekley (lebbeous)]

I ran a similar test to Dan's, but started arbitrarily with a 2.2.5 database, since it should work equally well from the middle of the 2.2 series. And it did.

Merging to master, rel_2_4 and rel_2_3. Thanks all.