[OPEN-ILS-GENERAL] community support policy for Evergreen releases?

[Duimovich, George]

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: open-ils-general-bounces at list.georgialibraries.org [mailto:open-ils-general-bounces at list.georgialibraries.org] 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:  jason at esilibrary.com
 | web:  http://www.esilibrary.com