[OPEN-ILS-DEV] Suggestion for New Upgrade Script Policy

[Dan Wells]

Hello all,

I know that eventually we want to move toward a more fluid DB upgrade model, but leaving that plan aside for the moment, I'd like to suggest a new policy for maintenance releases.

My sense is that, as Evergreen matures, people are staying on the previous version for longer periods, so it is becoming increasingly likely that the one-time upgrade moment (e.g. 2.5.3->2.6.0 ) won't be what most people need.  I propose that each maintenance release include two scripts instead of just the one we do now.  For maintenance releases, we currently generate only an upgrade script from minor to minor within the same major release (e.g. 2.5.4 -> 2.5.5 and 2.6.0 -> 2.6.1).  For completeness, though, we really also need a minor to minor upgrade *across* the major releases (e.g. 2.5.5 -> 2.6.1).

Doing this would mean more work for the maintainers, but I think it would be worth it, since newest to newest is the most sensible upgrade path at any given time.  If we start doing this, I would also suggest that maintenance releases be staggered by one week to minimize potential churn (i.e. 2.5.5 should be fully settled before we try to make a 2.5.5->2.6.1 script).  The alternative would be to make, in this case, a 2.5.4->2.6.1 upgrade, but that would mean the cross-version script would always lag behind.

So, this is really two proposals to vote/comment on:

1) Should we add a new maintenance requirement of creating minor-to-minor scripts across major versions with every release?
2) Should we stagger maintenance releases by one week, ordered by oldest to newest maintained release?  (e.g. 2.5.x first, 2.6.x a week later)

Thanks,
Dan


Daniel Wells
Library Programmer/Analyst
Hekman Library, Calvin College
616.526.7133



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140530/52d0b961/attachment.htm>