Dan,
It does seem like there is a considerable amount of pain posted to the
lists by folks that have to deal with so many minor upgrade scripts. If
this would help cut down on that, then +1
Justin
On Fri May 30 14:23:21 2014, Dan Wells wrote:
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
