I should note for the mailing list that all the numbered examples I
gave were entirely fictional and meant to be representative of the
concept contained there-in, not any actual working values for any real
versions of Evergreen.

-- Ben

On Fri, Mar 13, 2015 at 4:00 PM, Ben Shum <[email protected]> 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.
>
> 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



-- 
Benjamin Shum
Evergreen Systems Manager
Bibliomation, Inc.
24 Wooster Ave.
Waterbury, CT 06708
203-577-4070, ext. 113

Reply via email to