Mike, I was composing my response to Ben's message as yours came in, but it sounds like what you're proposing below is very much in line with what I was imagining.
I'd be willing to assist in making this happen, since I think it would benefit us all. Thanks! Chris ----- Original Message ----- > From: "Mike Rylander" <mrylan...@gmail.com> > To: "Evergreen Discussion Group" <open-ils-general@list.georgialibraries.org> > Sent: Friday, March 13, 2015 4:07:51 PM > Subject: Re: [OPEN-ILS-GENERAL] Upgrade Script for 2.6.4 to 2.7 > > Chris, > > That's what I've advocated for in the past (see upgrade scripts 0526 and > 0537), via a helper script that 1) only applies what's needed (based on > config.upgrade_log) and 2) knows how to look up supersedes/deprecated-by > info from within the scripts. Writing down a detailed plan keeps getting > back-burnered, but there are at least four different scripts floating > around that attempt to do various versions of that. > > tl;dr of such a thing: all that's really needed to make that work is > 1) a concerted effort by devs to do things like supplying fine-grained db > scripts, particularly "reingest-only" scripts when a reingest is needed > 2) RM involvement in the creation of per-release scripts that do just > what's needed for the upgrade proper (like, do one and only one reingest) > 3) inclusion of supersedes/deprecated-by info in upgrade scripts that do, > in fact, supersede (or are deprecated by) early scripts > 4) a (say) perl script to read all the upgrade scripts and apply them in > order, as needed, based on config.upgrade_log > > > > -- > Mike Rylander > | President > | Equinox Software, Inc. / The Open Source Experts > | phone: 1-877-OPEN-ILS (673-6457) > | email: mi...@esilibrary.com > | web: http://www.esilibrary.com -- Chris Sharp PINES System Administrator Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, Georgia 30345 (404) 235-7147 csh...@georgialibraries.org http://pines.georgialibraries.org/