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

[George Tuttle]

Is there a process for beta testing Evergreen?

George Tuttle
Computer Services Librarian
Piedmont Regional Library System
770-867-2762 x113
770-891-0654 (cell)
770-867-7483 (fax)
gtuttle at prlib.org


-----Original Message-----
From: open-ils-general-bounces at list.georgialibraries.org
[mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of
Duimovich, George
Sent: Monday, September 26, 2011 12:06 PM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] community support policy for Evergreen
releases?


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