There's going to be folks who can upgrade 'the day of release' and others with
constraints that prevent those just-released upgrades from happening in a
timely manner (e.g. larger consortia, academics with school term timing issues,
etc.).
So supporting older versions is important, but I'm for the view that we don't
go too far back with that, given how important it is to keep the Evergreen
train moving fast and development/support resources focussed.
To make it easier and help manage the pace of upgrades, I'm always recommending
to potential new users to look into negotiating vendor support agreements that
come with "X free upgrades" - this has helped us critically from time to time.
Also nice that Canadian / US holidays don't always match up, so convenient to
pass the buck once in a while to help manage upgrades esp. during those lazy
summer holidays.
Also related to keeping up with the upgrades:
1) The patching and bug fixing seems to be fast - like lightning fast in most
cases - and this seems to be getting better as there are more of us out there
to test new releases, but a bit more QA somewhere in the chain could help
reduce the number of minor dot (re)-releases, which in turn might reduce any
"upgrade fatigue" for some users and/or helping better conserve upgrading
resources for the major releases.
2) Re-integrating our customizations - continues to be a pain point. To be
clear, this is a nice problem to have given that previous ILS didn't have this
"problem" -- i.e. wouldn't let us customize. And there's been significant
progress since we started on 1.4 (yah!), but I've often thought that our
in-house "upgrade checklist" has a few too many little gotchas to review with
each upgrade. With the experience we have now, it's no big deal but a bit
annoying when other issues also come into play to burn into the upgrade
process. It doesn't help that most IT units are being squeezed to do more with
less, so important that we continue to make headway towards customization-happy
upgrades
(TT opac and other planned changes to help) and staff-client friendly
auto-updates, etc.
I'm not sure where the sweet spot lies with selecting time-based support
periods ("tough love" approach) and/or more structured Long Term Support
releases but I guess what we're trying to avoid here is the problem that
plagues other ILS communities: namely, lots of end users running way out of
date systems, then running into troubles with support and/or consuming limited
resources on yesterday's problems (ultimately leading to more expensive
upgrades down the road and a bad rap for rest of community).
Finally, hosted options offer *some* libraries an extremely good option to
resolve the keeping up-to-date problem, so I'd anticipate that long term
support is not as critical as it may have in the past.
George
George Duimovich
NRCan Library / Bibliothèque de RNCan
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Jason
Etheridge
Sent: September 23, 2011 15:33
To: Evergreen Discussion Group; Evergreen Development Discussion List
Subject: [OPEN-ILS-GENERAL] community support policy for Evergreen releases?
During the Community meeting in IRC today, I asked "if we really want to push
out 2.2 quickly, might we extend support for whatever version would be falling
off the support truck? or is that a bad idea?"
According to the last policy we came up with, 1.6 would be deprecated as soon
as 2.1 hits, and 2.0 will be deprecated as soon as 2.2 hits.
There were musings about time-based support periods and Long Term Support
releases, and it was decided we'd talk about such things on list.
So. Discuss. :)
--
Jason Etheridge
| Equinox Software, Inc. / Your Library's Guide to Open Source
| phone: 1-877-OPEN-ILS (673-6457)
| email: [email protected]
| web: http://www.esilibrary.com
