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

[Mike Rylander]

On Fri, Mar 13, 2015 at 4:00 PM, Ben Shum <bshum at biblio.org> wrote:

> 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.
>
>
FWIW, if folks are reusing numbers for similar-but-different in back
branches (as in, same effect, different code) then they're doing it wrong.
It's happened a couple times in the past and is nothing but trouble.

The rule is: every upgrade script number should be allocated in master,
even if the script in master may be effectively empty (just a
config.upgrade_log entry), as would be the case when the change is only
needed in a back branch.

--miker

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
> <csharp at georgialibraries.org> 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" <gmc at esilibrary.com>
> >> To: "Evergreen Discussion Group" <
> open-ils-general at list.georgialibraries.org>
> >> 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 <
> >> alexey.lazar at mnsu.edu> 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:  gmc at esilibrary.com
> >> 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
> > csharp at georgialibraries.org
> > http://pines.georgialibraries.org/
>
>
>
> --
> Benjamin Shum
> Evergreen Systems Manager
> Bibliomation, Inc.
> 24 Wooster Ave.
> Waterbury, CT 06708
> 203-577-4070, ext. 113
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20150313/44908d1d/attachment.html>