Without getting into too detailed or specifics, but.... 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. 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 would say that this is the main reason our library system has stuck to master so that we have an unbroken chain of upgrade script by the numbers without any confusion of when to apply X or Y, etc. Perhaps not helpful, but some background thoughts to the mix. -- Ben On Fri, Mar 13, 2015 at 3:47 PM, Chris Sharp <[email protected]> wrote: > Since that's true... > > Couldn't we develop some sort of upgrade mechanism that just aggregates and > runs each of the constituent scripts? What is the reasoning behind stringing > them into the longer monolithic scripts since running through the numbered > scripts provides the same outcome? > > (Asking the full list, not Galen specifically). > > ----- Original Message ----- >> From: "Galen Charlton" <[email protected]> >> To: "Evergreen Discussion Group" <[email protected]> >> Sent: Friday, March 13, 2015 3:31:33 PM >> Subject: Re: [OPEN-ILS-GENERAL] Upgrade Script for 2.6.4 to 2.7 >> >> Hi, >> >> On Fri, Mar 13, 2015 at 1:51 PM, Lazar, Alexey Vladimirovich < >> [email protected]> wrote: >> > >> > Since an Open-ILS/src/sql/Pg/version-upgrade script is a subset of several >> > specific Open-ILS/src/sql/Pg/upgrade/XXXX scripts, is there any harm in >> > just applying the XXXX scripts separately, in the order they appear, to get >> > the database up to a certain “version" number? >> > >> >> That approach will work just fine, though checking through all of the point >> schema upgrades you plan to apply and seeing if there are any redundant bib >> reingests that you can skip can save you some time. >> >> Regards, >> >> Galen >> -- >> Galen Charlton >> Infrastructure and Added Services Manager >> Equinox Software, Inc. / The Open Source Experts >> email: [email protected] >> direct: +1 770-709-5581 >> cell: +1 404-984-4366 >> skype: gmcharlt >> web: http://www.esilibrary.com/ >> Supporting Koha and Evergreen: http://koha-community.org & >> http://evergreen-ils.org >> > > -- > Chris Sharp > PINES System Administrator > Georgia Public Library Service > 1800 Century Place, Suite 150 > Atlanta, Georgia 30345 > (404) 235-7147 > [email protected] > http://pines.georgialibraries.org/ -- Benjamin Shum Evergreen Systems Manager Bibliomation, Inc. 24 Wooster Ave. Waterbury, CT 06708 203-577-4070, ext. 113
