[OPEN-ILS-GENERAL] Upgrade Script for 2.6.4 to 2.7

[Chris Sharp]

Thanks for the quick and detailed response, Ben.

> While the numbers for upgrade scripts are purely sequential in master,
> they are not complete and sequential for upgrades in release branches,
> at least once you start talking maintenance releases since we do not
> always backport every upgrade script to previous versions of
> Evergreen.
> 
> So if an upgrade script went 0001, 0002, 0003, etc. through release
> 2.7.0, then we started developing for 2.8 series and the numbers
> continued, 0004, 0005, 0006, etc. then there might be gaps where
> things did not backport cleanly.
> 
> So if 0005 was backported, but 0004 and 0006 was not, then the upgrade
> scripts in 2.7 might look like 0001, 0002, 0003, 0005, while the chain
> would remain unbroken in 2.8/master.  If you then upgraded from 2.7 to
> 2.8, how would you know which you missed or didn't already get?  What
> if 0005 applied a fix for something that was changed in 0004.  So if
> you ran 0004 and not 0005 (a second time during the upgrade), your
> system breaks with an older bad upgrade script function.

I would be interested in seeing a system that did something where the Evergreen 2.5.1-2.7.0 upgrade script (for example) was really just a wrapper that said "run scripts 0001, 0002, 0003, 0005, and 0010".  It would also be nice if something in the database (maybe expanding config.upgrade_log?) would "know" which scripts constituted which version upgrade.

People running sequentially through the scripts to stay on master are already "out-of-band" as far as releases go, so they would be left to manage the process on their own.  Though it would be useful for the system to "know" that the system they are running is equivalent to "2.7.2 + scripts 0045 and 0046" for comparison purposes.

> Creating a giant version-upgrade script is how things have been done
> to this point, but moving between major versions can still be fraught
> with strangeness in the upgrade scripts even if you face each one on
> its own.
> 
> That said, we're getting better about making good upgrade scripts that
> don't stack against each other or cause disruptions.

I agree with this.  The last three upgrades have been much smoother from my perspective.

Thanks!

Chris

-- 
Chris Sharp
PINES System Administrator
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, Georgia 30345
(404) 235-7147
csharp at georgialibraries.org
http://pines.georgialibraries.org/