[Evergreen-general] [External] Tell us about your upgrade schedules!

Fri Feb 21 14:58:22 EST 2025

Thank you for all the detailed information, Benjamin! This is all very
helpful.

This past year we were chasing the latest version which I don't think we're
> going to do again. We weren't able to test the Reporter changes in 3.13, so
> we got hit with a lot of tickets for bugs once it went live. Some of them
> we were able to chase fixes for, some we had to just report on Launchpad
> and hope someone took them on. This is frustrating for our users, so we're
> thinking about being more conservative about upgrading to the latest
> version. That's one of the challenges of an open source project, if you're
> on the cutting edge, find a bug and don't have the resources to fix it
> yourself, you might be stuck with the problem for a while. Your user base
> doesn't always understand that.

I think this is one of my primary concerns. By staying one release behind,
we typically have a chance to test all of the major changes to ensure that
there won't be any dealbreaker bugs that cause too much of a hardship for
our users. Going to an annual schedule will require us to upgrade to a
newer release since we don't want to move outside the window of security
fixes. We won't have as much time to test those large changes,
especially if there are delays in the community release schedule. But our
recent release teams have been great about keeping the community on
schedule, and I'm hopeful it will help us with our process to fully vet a
release before an upgrade.

Have a good weekend!
Kathy
--
Kathy Lussier
she/her
Executive Director
NOBLE: North of Boston Library Exchange
Danvers, MA
978-777-8844 x201
www.noblenet.org

On Fri, Feb 21, 2025 at 1:46 PM Murphy, Benjamin <
Benjamin.Murphy at dncr.nc.gov> wrote:

> Our consortium upgrades annually in the fall and we typically skip a
> version (3.11.3 to 3.13.5 for instance.) We usually install the target
> version on a test machine in early summer and then invite staff in
> consortium libraries to kick the tires over the summer so we can make/seek
> patches to issues and prepare solid training of what to expect. We have a
> mailing list (Basecamp group) targeted specifically to testing that we
> invite people to join and discuss issues they encounter. (Let me add a plug
> for the session at the upcoming conference about Collaborative Testing.
> This is something we're trying to wrap our heads around and I'm interested
> to hear what they have to say.) After testing over the summer, we then have
> webinars for the larger community to discuss and prepare for upgrade
> changes.
>
> We have our upgrade documentation here:
> https://nccardinalsupport.org/index.php?pg=kb.book&id=10 including our
> working list of known but unresolved bugs.
>
> This past year we were chasing the latest version which I don't think
> we're going to do again. We weren't able to test the Reporter changes in
> 3.13, so we got hit with a lot of tickets for bugs once it went live. Some
> of them we were able to chase fixes for, some we had to just report on
> Launchpad and hope someone took them on. This is frustrating for our users,
> so we're thinking about being more conservative about upgrading to the
> latest version. That's one of the challenges of an open source project, if
> you're on the cutting edge, find a bug and don't have the resources to fix
> it yourself, you might be stuck with the problem for a while. Your user
> base doesn't always understand that.
>
> "Do you just load bug fixes as you need them?" We did one "mini-upgrade"
> in spring a few years back, but generally we have to be offline for ~36-48
> hours for an upgrade, deal with training and all the other logistics so we
> usually just stick to once a year.
>
> "is there any frustration among your libraries about delays in getting new
> features?" We've heard some excitement about new features for member
> library staff that are plugged into the larger Evergreen community, but we
> hear more frustration when new things don't work.
>
> After our most recent upgrade, we decided as a team that we're going to
> treat our upgrades more like a new library migration, where we're all
> focused on some aspect of the upgrade for a period of time and try to be
> more deliberate about testing, user engagement, etc.
>
> I'm interested to hear what other folks have to say on the topic.
>
> *Benjamin Murphy*
>
> NC Cardinal Program Manager
>
> State Library of North Carolina
>
> *benjamin.murphy at dncr.nc.gov <benjamin.murphy at dncr.nc.gov> * |
> https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal
>
> 109 East Jones Street  | 4640 Mail Service Center
>
> Raleigh, North Carolina 27699-4600
>
> The State Library is part of the NC Department of Natural & Cultural
> Resources.
>
> *Email correspondence to and from this address is subject to the North
> Carolina Public Records Law and may be disclosed to third parties.*
>
>
> ------------------------------
> *From:* Evergreen-general <
> evergreen-general-bounces at list.evergreen-ils.org> on behalf of Lussier,
> Kathy via Evergreen-general <evergreen-general at list.evergreen-ils.org>
> *Sent:* Friday, February 21, 2025 11:48 AM
> *To:* Evergreen Discussion Group <evergreen-general at list.evergreen-ils.org
> >
> *Cc:* Lussier, Kathy <klussier at noblenet.org>
> *Subject:* [External] [Evergreen-general] Tell us about your upgrade
> schedules!
>
> *CAUTION:* External email. Do not click links or open attachments unless
> verified. Report suspicious emails with the Report Message button located
> on your Outlook menu bar on the Home tab.
>
> Hi all and Happy Friday!
>
> NOBLE is reevaluating its upgrade schedule and would like to hear how
> other libraries / consortia handle their upgrades. Since we moved to
> Evergreen, we've been on a schedule to do a major release upgrade twice per
> year, following the community's schedule of two releases per year, and
> usually upgrade to the release that's one version behind the latest
> release. We don't typically do point release upgrades, but will load
> patches for bug fixes that are important to our libraries. We also hold off
> on upgrades in cases where we see bugs that will cause too much of a
> hardship for our libraries. This typically happens when an entire interface
> is replaced before it supports all of the features used by our libraries.
>
> We are considering a move to a one-upgrade-per-year schedule. Under this
> schedule, we would skip a release to ensure we stay on a release that still
> receives security fixes.
>
> Tell us about your upgrade schedules.
>
>    - What is your current upgrade schedule for major releases? Do you
>    typically upgrade one release at a time or do you skip releases?
>    - Do you typically perform point release upgrades in addition to major
>    upgrades? Do you just load bug fixes as you need them? Or do you do both
>    (or neither)?
>    - Has your upgrade schedule changed over the years that you’ve been on
>    Evergreen? If so, how has it changed and what factors influenced your
>    decision to make those changes?
>    - If your upgrade schedule is annual or even less frequent, is there
>    any frustration among your libraries about delays in getting new features?
>
> Feel free to add any information about what you like or dislike about your
> current schedule.
>
> Adding a #CatTax in appreciation for your feedback.
>
> [image: PXL_20231003_205444966.jpg]
>
> Kathy
> --
> Kathy Lussier
> she/her
> Executive Director
> NOBLE: North of Boston Library Exchange
> Danvers, MA
> 978-777-8844 x201
> www.noblenet.org
>
>
>
> ------------------------------
>
> Email correspondence to and from this address may be subject to the North
> Carolina Public Records Law and may be disclosed to third parties by an
> authorized state official.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20250221/896d59dc/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PXL_20231003_205444966.jpg
Type: image/jpeg
Size: 188370 bytes
Desc: not available
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20250221/896d59dc/attachment-0001.jpg>